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ABSTRACT 


The  objective  of  this  thesis  is  to  analyze  the  fleet  mix  planning  problem, 
develop  an  approach  to  evaluate  alternative  fleet  mixes,  and  implement  the 
approach  in  a  decision  support  system  (DSS).  In  particular,  this  research  is 
conducted  in  the  context  of  the  acquisition  of  a  mix  of  patrol  boats  to  replace 
the  aging  Point  Class  patrol  boats  within  the  U.  S.  Coast  Guard.  The  analysis 
of  an  alternative  fleet  mix  involves,  among  other  things,  the  evaluation  of 
cost,  activity  and  performance  measures  for  that  fleet  mix.  Several  analytic 
and  forecasting  models  are  used  to  determine  costs  and  activity  measures  for 
various  fleet  mixes,  and  simulation  games  are  played  to  assess  expected 
mission  performance  for  each  mix  under  a  set  of  mission  scenarios.  A  rule- 
based  deductive  model  is  employed  to  determine  and  score  the  response  of  a 
given  fleet  mix  to  events  occurring  during  the  simulation.  These  models  are 
implemented  and  integrated  in  a  decision  support  system  which  combines 
the  mathematical  models  with  a  database  system,  an  expert  system,  and  user 
interface  tools.  It  is  hoped  that  repeated  use  of  the  system,  analysis  of  the 
alternative  fleet  mixes  using  a  large  number  of  data  sets,  and  post-evaluation 
analysis  and  explanations,  will  help  provide  the  decision-maker  insight  in  to 
the  problem,  and  will  facilitate  a  judicious  decision. 
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I.  INTRODUCTION 


This  research  examines  and  analyzes  the  fleet  mix  planning  problem, 
develops  a  simulation  approach  to  evaluate  the  performance  of  alternative 
fleet  mixes,  and  implements  this  method  in  a  decision  support  system  (DSS). 
Further,  we  present  and  apply  our  solution  approach  for  fleet  mix  planning 
in  the  context  of  patrol  boat  acquisition  within  the  United  States  Coast  Guard 
(USCG).  The  DSS  presents  evaluation  results  for  alternative  fleet  mixes, 
allowing  a  decision  maker  the  ability  to  make  comparisons  and  decisions. 
The  system  is  being  used  by  the  USCG  which  provided  us  with  an  ideal 
application  within  the  Patrol  Boat  Capability  Replacement  Project  office. 

A.  BACKGROUND 

Fleet  mix  planning  is  an  important  issue  within  many  organizations 
including  rental  vehicle  companies,  the  U.S.  Navy  and  the  U.  S.  Coast  Guard. 
This  section  provides  an  overview  of  the  fleet  mix  problem  with  specific 
references  to  the  Coast  Guard  patrol  boat  fleet  mix. 

1.  Fleet  Mix 

Broadly  defined,  a  fleet  mix  is  a  combination  of  various  assets.  Within 
our  scope  a  fleet  mix  is  defined  as  a  combination  of  various  vessels,  assigned 
to  specific  homeports,  that  have  been  selected  to  maximize  performance  or 
minimize  costs  while  meeting  the  requirements  of  the  assigned  mission.  An 
example  of  a  fleet  mix  is  a  nationwide  car  rental  agency.  The  agency  operates 
in  an  industry  where  having  the  right  mix  of  cars  is  crucial  to  competing  with 
other  agencies.  The  similarities  between  a  car  rental  agency  and  the  Coast 
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Guard  are  limited,  but  word;  a  brief  comparison.  Both  are  required  to  provide 
the  proper  mix  of  assets  to  their  selected  locations.  Both  also  schedule 
maintenance  periods  for  assets  while  still  meeting  their  mission  objectives. 
In  addition,  both  must  have  rapid  availability  on  short  notice. 

2.  Patrol  Boat  Fleet  Mix 

The  Coast  Guard  has  traditionally  called  its  vessels  cutters  and 
distinguished  those  that  are  80  to  120  feet  in  length  by  referring  to  them  as 
patrol  boat  cutters  [Ref.  l:p.  14].  The  Coast  Guard  currently  has  approxir^ately 
100  patrol  boats  that  operate  in  eight  coastal  districts  throughout  the  United 
States,  including  Hawaii  and  Alaska.  The  patrol  boat  fleet  consists  mainly  of 
boats  in  two  classes:  the  Point  class  and  the  Island  class.  The  primary  mission 
requirements  of  the  patrol  boat  fleet  are  enforcement  of  law  and  treaties^ 
(ELT),  search  and  rescue  (SAR),  and  defense  operations  [Ref.  l:p.  14]. 
Secondary  missions  are  marine  environmental  protection  (MEP),  marine 
safety  and  aids  to  navigation. 

3.  Replacing  the  Point  Class  Patrol  Boat 

The  Point  Class  patrol  boats  are  approaching  the  end  of  their  useful 
service  life.  The  Coast  Guard  is  planning  to  retire  the  aging  Point  class  patrol 
boats  gradually  during  the  decade  of  the  1990's  [Rt  ’  Z:p.  1-1].  The  Patrol  Boat 
Capability  Replacement  Project  office  is  studying  candidate  replacement 
cutters  that  can  fulfill  mission  requirements  and  have  better  performance 
than  its  predecessor. 


^Drug  interdiction  is  a  highly  visible  mission  and  a  part  of  ELT. 
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4.  Candidate  Replacement  Cutters 

There  are  three  candidate  replacement  cutters  being  considered  by  the 
Patrol  Boat  Capability  Replacement  Project  office.  The  first  is  the  Island  class 
patrol  boat  that  has  a  length  of  110  feet.  This  patrol  boat  class  has  been  in 
service  since  1983  and  is  still  being  built  for  the  Coast  Guard.  The  Coast  Guard 
plans  to  acquire  47  of  these  patrol  boats.  The  second  candidate  is  the  Heritage 
class  patrol  boat  that  has  a  length  of  120  feet.  This  cutter  was  designed  by  the 
Coast  Guard  Naval  Engineering  division  for  improved  stability  and 
endurance  over  previously  designed  patrol  boats  [Ref.  2:  p.  2-14].  The 
prototype  ship  is  expected  to  be  completed  in  1992.  The  third  candidate 
replacement  cutter  is  the  notional  design  patrol  boat.  Initial  design  studies  are 
still  in  progress.  Preliminary  design  objectives  for  the  vessel  include  a 
shallow  draft  with  a  length  of  75  to  85  ft. 

5.  Reasons  for  a  Mixed  fleet 

Each  candidate  replacement  class  has  certain  advantages  and 
disadvantages  when  compared  to  the  other  classes  [Ref.  2].  For  example,  the  80 
foot  Notional  design  craft  would  require  fewer  crew  (therefore,  lower 
personnel  costs),  would  be  more  fuel  efficient  at  a  given  speed,  and  would 
have  a  shallower  draft  than  either  the  Heritage  or  Island  class  patrol  boats. 
These  benefits  could  be  significant  if  the  mission  requirement  was  primarily 
SAR,  where  a  small,  nimble  and  shallow  draft  vessel  could  maneuver  near 
shoal  water. 

However,  the  Notional  design  would  have  a  lesser  endurance  of  three 
days  compared  to  five  or  seven  days  for  the  other  two  candidate  patrol  boats. 
The  vessel  would  be  less  stable  in  heavy  seas.  With  a  smaller  crew,  the 
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notional  design  would  also  have  difficulty  supplying  a  four  or  five  member 
boarding  party^.  These  limitations  would  hinder  the  Notional  patrol  boat  as  a 
drug  interdiction  vessel,  where  endurance  and  boarding  parties  are  important 
factors. 

Utilizing  a  mixed  patrol  boat  fleet  gives  the  Coast  Guard  a  higher 
flexibility  in  accomplishing  its  mission  objectives.  Limiting  replacement  of 
the  Point  class  patrol  boat  to  one  class  of  vessels  would  restrict  selection 
opportunities.  The  tradeoffs  between  various  kinds  of  vessels  and  the  need  to 
diversify  the  fleet  are  important  considerations.  A  decision  to  improve  the 
capability  of  the  fleet  in  one  evaluation  category  will  most  often  result  in  a 
tradeoff  or  degradation  in  another  category.  For  example,  patrol  boats  could 
be  designed  with  larger  fuel  tanks  and  more  bunks  for  watchstanders,  to 
provide  an  increased  endurance  at  sea.  The  tradeoff  is  that  the  cost  of  the 
vessel  would  increase,  and  maximum  speed  of  the  patrol  boat  would  likely  be 
reduced  for  a  given  engine  horsepower.  Similarly,  a  decision  to  reduce  the 
costs  in  one  category  (acquisition  cost)  will  most  often  require  a  higher  cost  in 
another  area  (maintenance  costs)  or  may  cause  degradation  in  a  capability 
(lower  maximum  speed). 

6.  Complexity  of  Fleet  Mix  Planning 

Many  factors  must  be  considered  when  selecting  a  fleet  mix.  A  new 
fleet  is  not  restricted  to  being  uniform  with  respect  to  type,  size,  or 
configuration  of  vessel.  Figure  1  illustrates  the  complexity  of  the  replacement 


2A  boarding  party  is  used  to  inspect  other  vessels  for  compliance  with  U. 
S.  laws  and  treaties.  A  small  boat  is  sent  from  the  patrol  boat  to  the  other 
vessel.  Five  personnel  are  normally  needed  for  this  operation. 
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process.  The  Patrol  Boat  Capability  Replacement  Project  office  must  contend 
with  all  of  these  factors.  These  complex  factors  are  individually  presented  in 
Chapter  n.  Simply  stated,  the  task  is  to  determine  a  fleet  mix  for  a  given  time 
frame,  that  will  fulfill  mission  requirements,  and  any  new  unknown 
requirements,  given  that  only  X  number  of  boats  can  be  built  per  year,  and 
that  the  decision  is  restricted  by  a  congressionally  mandated  budget.  The 
decision  makers  must  consider  the  relative  advantages  and  disadvantages  of 
the  alternative  fleet  mixes. 
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Figure  1-1  Complexity  Issues  of  the  Replacement  Process. 


B.  RESEARCH  OBJECTIVES 

The  objectives  of  this  thesis  are  1)  to  propose  a  method  for  addressing  fleet 
mix  planning,  and  2)  to  design  a  prototype  DSS  that  will  support  the  specific 
application  in  patrol  boat  acquisition.  The  four  primary  research  questions 
that  are  guiding  this  thesis  are: 
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•  What  information  should  the  DSS  provide  to  facilitate  judicious  fleet 
mix  decision  making? 

•  What  information  presentation  approach  should  be  used  to  provide  the 
user  easy  access  to  concise  information? 

•  What  factors,  attributes,  or  characteristics  of  a  fleet  mix  are  relevant  in 
making  relative  comparisons  between  alternatives? 

•  What  factors  are  relevant  in  justifying  the  results  obtained  from  a  fleet 
mix  alternative? 

C  PROPOSED  SOLUTION 

Our  goal  has  been  to  develop  a  prototype  DSS  that  would  be  immediately 
useful  and  would  help  a  decision  maker  select  a  better  fleet  mix  alternative. 
This  paper  presents  an  approach  to  fleet  mix  planning  that  1)  assists  decision 
makers  in  developing  and  comparing  arguments  regarding  alternative 
courses  of  action,  2)  presents  the  attribute  measures  in  an  accessible  and  easy 
to  understand  format,  and  3)  provides  a  DSS  that  will  be  immediately  useful 
to  solve  part  of  the  fleet  mix  problem  [Ref.  3:p.  11-14]. 

D.  SCOPE 

The  focus  of  this  research  is  on  the  acquisition  of  patrol  boats  in  the  Coast 
Guard,  one  aspect  of  the  broader  fleet  mix  planning  process.  The  research  will 
design  and  develop  a  prototype  DSS  that  will  allow  Coast  Guard  planners  to: 


•  select  patrol  boats  for  the  fleet  mix  alternative.  Options  will  include  the 
82  ft.  Point  class3  (WPB  82),  the  110  ft.  Island  class  (WPB  110),  the  120  ft. 
Heritage  class  (WPB  120),  and  the  Notional  design  patrol  boat  (WPB  80). 
The  user  can  modify  any  characteristics  of  the  above  patrol  boats. 
Additional  DSS  features  allow  new  patrol  boat  classes  to  be  defined  by 
the  user. 


^Though  the  Point  class  patrol  boats  will  be  retired  soon,  the  class  is 
included  to  provide  the  baseline  fleet  mix. 
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•  define  or  modify  homeport  assignment  of  each  patrol  boat  within  a  fleet 
mix. 

•  compose  multiple  fleet  mix  alternatives. 

•  evaluate  fleet  mix  alternatives  on  the  basis  of  cost,  activity,  and 
performance  measures. 

For  demonstration  purposes,  we  will  evaluate  three  fleet  mix  alternatives 
proposed  by  the  Coast  Guard.  The  selected  fleet  mixes  are:  a  fleet  mix 
consisting  of  the  present  mix  of  patrol  boats^,  and  two  hypothetical  fleet  mix 
alternatives.  The  present  fleet  mix  will  serve  as  a  baseline  for  comparison 
studies. 

The  research  will  not: 

•  evaluate  helicopters  and  other  airborne  Coast  Guard  assets. 

•  evaluate  other  missions  of  the  USCG  (i.e.  buoy  tending  and  polar 
operations) 

•  provide  an  absolute  value  of  fleet  mix  performance.  The  DSS  will 
provide  relative  performance  measures  that  can  be  compared  to  other 
fleet  mix  alternatives. 

•  rank  order  fleet  mix  alternatives.  Instead  the  decision  maker  compares 
the  evaluation  results,  assigns  his  own  relative  weight  to  the  displayed 
performance  measures,  and  selects  the  better  fleet  mix  alternative. 

E.  THESIS  ORGANIZATION 

Chapter  II  discusses  the  fleet  mix  planning  problem  and  presents  an 
alternative  solution  approach  to  the  problem.  Chapter  III  presents  the  fleet 
mix  DSS  design  and  introduces  our  functional  approach.  Chapter  IV  discuses 
the  implementation  of  the  fleet  mix  DSS.  Fleet  Mix  analysis  is  discused  in 
Chapter  V.  In  Chapter  VI  we  summarize  the  findings  and  propose  ideas  for 
further  research. 


'^The  baseline  fleet  mix  uses  the  patrol  boats  operating  on  January  1,  1991. 
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II.  THE  FLEET  MIX  DECISION  MODEL 


This  chapter  provides  an  overview  of  the  fleet  mix  decision  environment  as  it 
relates  to  patrol  boat  replacement  in  the  U.  S.  Coast  Guard.  It  also  introduces  our 
approach  for  decision  making  in  this  context.  The  first  section  describes  the  fleet 
mix  planning  problem.  The  second  section  discusses  various  stages  in  the  fleet 
mix  decision  process.  The  third  section  discusses  alternative  approaches  for 
solving  fleet  mix  problems.  The  last  section  presents  an  overview  of  our  solution 
approach. 

A.  THE  FLEET  MIX  PLANNING  PROBLEM 

The  patrol  boat  fleet  mix  planning  problem  is  complex  and  has  been  a  major 
consideration  of  the  Coast  Guard's  Patrol  Boat  Capability  Replacement 
Acquisition  project.  New  patrol  boats  are  needed  during  the  1990's  to  replace  the 
Point  class  patrol  boats.  The  following  questions  are  typical  of  the  questions 
facing  the  Patrol  boat  planners.  How  many  patrol  boats  are  needed  to  meet  the 
mission  requirements?  What  types  of  patrol  boats  are  most  cost  effective  in  the 
fleet  mix?  How  many  of  each  type  should  be  purchased?  Where  should  the 
patrol  boats  be  located  to  best  fulfill  the  mission  requ  ’  nents? 

We  analyze  the  fleet  mix  planning  problem  by  considering  the  following 
aspects  in  this  section:  uncertainty,  objectives  and  constraints,  evaluation  criteria, 
variables,  and  information  requirements. 

1.  Uncertainty 

The  planning  of  a  fleet  mix  is  complicated  by  various  kinds  of  uncertainty. 
There  is  uncertainty  about  the  type  of  activities  that  will  be  assigned  to  patrol 
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boats  in  the  future  [Ref.  3:p.  14].  As  stated  in  Chapter  1,  the  primary  mission 
areas  for  patrol  boats  are  currently  SAR  and  drug  interdiction  (ELT).  The  SAR 
mission  may  be  assigned  to  patrol  boats,  helicopters,  fixed  wing  aircraft  or  other 
Coast  Guard  vessels,  depending  on  the  nature  of  the  incident,  the  location  of  the 
incident  and  assets  available  for  response.  The  drug  interdiction  mission  is 
currently  assigned  to  patrol  boats,  aircraft,  aerostats,  and  other  sensors  and  assets 
outside  the  Coast  Guard.  In  the  future,  the  mission  emphasis  for  patrol  boats 
may  change.  For  example  the  Coast  Guard  may  not  be  involved  in  towing 
vessels  to  port,  but  instead  would  arrange  to  have  disabled  vessels  towed  to  port 
by  a  private  rescue  company  hired  by  the  boat  owner. 

There  is  uncertainty  about  the  future  demand  for  Coast  Guard  patrol  boat 
response.  The  demand  for  a  given  day  is  the  number  of  boating  accidents  or 
drug  activity  in  the  coastal  waters  that  require  patrol  boat  response.  The 
geographic  distribution  (location)  of  future  activity  is  also  unknown.  For 
example,  the  information  about  where  incidents  will  occur,  when  they  will  occur 
and  the  type  of  response  required  by  the  Coast  Guard  is  difficult  to  predict,  even 
in  terms  of  probability  distributions.  Fundamental  changes  in  our  society,  such 
as  changes  in  boating  patterns,  a  dramatic  rise  in  fuel  prices  or  elimination  of 
illicit  drug  use  could  affect  the  demand  for  patrol  boats. 

2.  Patrol  Boat  Fleet  Mix  Objectives  and  Constraints 

The  Coast  Guard  patrol  boat  capability  replacement  project  prepared  a 
Mission  Needs  Statement  in  1983  for  the  patrol  boat  replacement  study.  A  partial 
listing  is  presented  below.  The  patrol  boat  replacement  "must  possess  the 
capability  to: 

Perform  multi-mission  patrols  in  coastal  waters  with  an  endurance  of 
approximately  five  days. 
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Intercept,  overtake  and  maintain  hot  pursuit  of  waterborne  craft  normally 
used  for  illicit  operations. 

Provide  a  five  person  custody  crew  to  sail  a  seized  vessel  up  to  24  hours 
while  escorting  the  vessel  and  the  custody  crew. 

Carry  out  all  described  activities  in  10-foot  high  sea  conditions,  and  be  able 
to  operate  at  a  reduced  performance  level  in  25-foot  seas  and  60  knot 
winds."  [  Ref.  4:p.  4] 

Constraints  on  the  fleet  mix  planning  problem  limit  the  range  of  solution 

possibilities.  Following  is  a  brief  look  at  the  constraints  imposed: 

•  Budget.  Proposed  budgets  for  all  aspects  of  patrol  boat  acquisition, 
operations,  maintenance  and  retirement  must  be  approved  by  Congress. 

•  Personnel.  The  number  of  personnel  available  to  crew  patrol  boats.  A 
solution  that  requires  more  boats  than  can  be  operated  by  the  available 
personnel  would  be  infeasible. 

•  Geography.  The  Coast  Guard  has  selected  certain  ports  as  patrol  boat 
homeports.  Each  port  has  a  limited  pier  size,  a  limited  turning  basin  (for 
maneuvering  patrol  boats  near  the  pier)  and  limited  water  depth  in  the  sea 
access  channel.  Although  new  homeports  can  be  developed  and  access 
channels  can  be  dredged,  the  additional  expenses  incurred  must  be 
considered  in  the  process. 

•  Vessel  Capabilities.  Once  the  vessel  is  designed  and  built,  attempts  to 
improve  sea  keeping,  maximum  speed,  or  attempts  to  change  the  vessel 
dr^t  are  difficult  and  expensive. 

3.  Measurement  Criteria 

The  fleet  mix  decision  support  system  will  facilitate  the  comparison  of 
alternative  fleet  mixes.  The  relative  advantage  of  one  fleet  mix  alternative  over 
the  others  is  determined  by  comparing  the  various  measures  for  each  fleet  mix. 
We  define  three  types  of  measures  to  evaluate  a  fleet  mix.  These  are  measures  of 
mission  performance,  potential  activity  (capability),  and  costs. 

Performance  measures  indicate  how  well  a  fleet  might  accomplish  its 
mission.  The  measures  include  the  number  of  successful  missions,  the  average 
time  required  to  reach  the  scene  of  a  SAR  case  and  the  number  of  failed  missions. 
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Activity  measures  show  the  portion  of  time  used  (or  available)  for  each  of  the 
patrol  boat's  tasks.  These  measures  include  patrol  hours  and  maintenance  hours. 
Cost  measures  capture  the  cost  of  using  resources  by  the  patrol  boats  within  the 
fleet  mix.  Examples  include  personnel  costs  for  boat  crews,  operating  costs  and 
acquisition  cost. 

4.  Variables 

Analysis  of  a  fleet  mix  involves  the  study  of  important  variables  and 
problem  characteristics.  Consultation  with  the  Coast  Guard  patrol  boat 
replacement  project  and  other  Coast  Guard  experts  provided  insight  on  the 
selection  of  variables.  Additionally,  variables  were  selected  if  they  had  an  impact 
on  at  least  one  of  the  measures. 

Variables  in  a  decision  model  are  either  controllable,  uncontrollable  or 
outcome  variables  [Ref.  5:p.  106].  Those  variables  that  the  decision  maker  has 
measurable  effect  on  are  called  controllable  variables.  The  decision  maker  selects 
values  for  these  variables.  An  example  is  homeport  assignment  for  each  patrol 
boat  in  the  fleet  mix.  Uncontrollable  variables  are  not  under  the  control  of  the 
decision  maker.  Uncontrollable  variables  in  the  fleet  mix  problem  include 
weather  conditions,  the  number  of  drug  boats  attempting  to  enter  a  port  and  the 
number  of  SAR  cases  that  will  occur.  Outcome  variables  or  decision  variables  are 
the  results  of  a  decision  model.  The  decision  model  performs  an  evaluation 
based  on  the  values  of  the  controllable  variables  and  estimated  values  for  the 
uncontrollable  variables  to  produce  an  outcome  variable. 

5.  Data  Sources 

The  quality  and  availability  of  data  affect  the  quality  and  reliability  of  the 
analysis.  Two  categories  of  historical  data  are  important  when  analyzing  the 
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fleet  mix.  One  category  is  the  patrol  boat  operational  data.  This  class  includes  the 
percentage  of  time  spent  on  each  mission  objective,  and  each  aspect  of  the  costs 
involved  in  operating  a  patrol  boat  for  a  year.  Operational  data  has  been 
collected  by  the  Coast  Guard  to  support  various  decisions  in  the  patrol  boat 
acquisition  process.  The  second  category  is  the  environmental  data.  This  class 
includes  data  about  incidents  and  illicit  operations  that  occur  within  the  Coast 
Guard's  area  of  responsibility.  The  Coast  Guard  maintains  databases  to  collect, 
sort  and  retrieve  data  about  SAR  cases  and  law  enforcement  cases  (which  include 
ELT).  Details  about  unreported  accidents  and  illicit  activity  are  obviously  not 
available. 

B.  THE  FLEET  MIX  DECISION  PROCESS 

The  fleet  mix  planning  problem  encompasses  a  broad  range  of  decisions  from 
the  initial  acquisition  through  disposal  of  the  retired  hull.  The  focus  in  this 
research  is  on  the  acquisition  of  patrol  boats.  The  acquisition  decision  needs  to 
be  justified  to  the  Department  of  Transportation  and  Congress.  Factors  outside 
the  Coast  Guard  may  affect  the  fleet  mix  selected.  These  aspects  of  the  fleet  mix 
decision  process  are  discussed  below. 

1.  Decision  Lifecycle, 

Replacement  of  patrol  boats  requires  several  major  steps.  The  Office  of 
Management  and  Budget  has  defined  a  process  that  must  be  followed  when 
acquiring  new  major  systems,  including  a  new  class  of  patrol  boats.  The  A-109 
Circular  (1977)  requires  that  the  responsible  office  (USCG)  establish  mission 
needs  and  operational  requirements  for  the  new  system  (patrol  boats).  The  first 
four  milestones  and  three  phases  of  the  process  are  summarized  below  [Ref.  6:p. 
1-21. 
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•  Milestone  0;  The  Coast  Guard  determines  if  an  identified  mission  warrants 
the  study  of  alternative  concepts.  Identify  the  minimum  set  of  alternative 
concepts. 

•  Phase  I;  This  is  the  Concept  Exploration  and  Definition  Phase  where 
various  alternatives  are  explored  for  meeting  the  mission  needs,  and  the 
most  promising  concept  is  identified. 

•  Milestone  I:  The  Coast  Guard  deternaines  if  the  results  of  Phase  I  warrant 
establishing  a  new  acquisition  program. 

•  Phase  n:  This  is  the  Demonstration  and  Validation  phase.  Objectives  of 
this  phase  include  proving  the  capability  of  the  preferred  system  by 
developing  a  prototype  and  developing  analysis  for  supporting  the 
Milestone  11  decision. 

•  Milestone  II;  The  Coast  Guard  determines  if  phase  11  warrants  continuation, 
and  if  so,  establishes  a  development  baseline  containing  program  cost, 
schedule  and  performance  objectives  and  acceptable  variances. 

•  Phase  ni:  The  objectives  of  Phase  HI  are  to  develop  a  stable  ship  design, 
and  demonstrate  through  testing  that  the  system  capabilities  can  be  attained 
and  meet  the  mission  need. 

•  Milestone  III-  This  is  Production  Approval.  The  Coast  Guard  determines  if 
Phase  III  warrants  continuation  and  if  so,  establishes  a  production  baseline. 

The  fleet  mix  decision  lifecycle  also  includes  decisions  about  homeport 
assignment,  timing  of  mid-life  maintenance  to  the  patrol  boats  and  retirement  of 
patrol  boats.  Since  acquisition  is  the  current  concern  of  the  patrol  boat 
replacement  project,  this  research  will  focus  on  the  acquisition  process. 

2.  Justification  of  the  Decision. 

Each  decision  in  the  acquisition  process  is  reviewed  based  on  the 
justification  and  supporting  evidence  provided  by  the  responsible  office  (patrol 
boat  replacement  project).  With  tight  federal  budgets,  only  those  programs  that 
are  presented  as  meeting  a  real  need  and  are  cost  effective  will  be  approved. 
Weak  justification  and  lack  of  supporting  evidence  for  a  proposed  acquisition 
would  reduce  the  probability  of  the  acquisition  being  authorized  by  Congress. 
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Therefore  to  be  useful,  a  decision  support  system  must  have  features  to  provide 
supporting  evidence  and  justification  for  decisions. 

3.  Other  Factors  Affecting  the  Fleet  Mix  Decision. 

The  political  nature  of  the  congressional  appropriation  process  is  an 
unknown  factor  in  the  fleet  mix  decision.  The  decisions  regarding  patrol  boat 
construction  and  location  of  homeports  will  ultimately  be  approved,  modified  or 
rejected  by  Congress.  Their  decisions  may  not  reflect  the  depth  of  evidence 
supporting  one  alternative  over  another. 

C  ALTERNATIVE  SOLUTION  APPROACHES 

There  is  no  existing  integrated  set  of  models  that  provides  analysis  for  the 
whole  planning  problem.  At  least  a  small  set  of  models  of  the  Coast  Guard's 
patrol  boat  operation  is  necessary  to  evaluate  and  compare  fleet  mix  alternatives. 
One  alternative  fleet  mix  approach  is  presented  below. 

1.  The  Balance  Sheet  Approach 

[Ref.  3]  states  that  the  fleet  mix  problem  is  conceptually  an  optimization 
problem  with  multiple  objectives  in  an  uncertain  environment.  The  authors 
point  out  practical  problems  with  a  single  large,  complex,  multiobjective 
stochastic  model.  They  used  a  DSS  approach  to  so’  Tig  the  fleet  mix  problem 
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[Ref.  3:p.  11].  The  DSS  was  designed  to  help  decision  makers  in  developing  and 
comparing  arguments  regarding  alternative  courses  of  action.  In  the  balance 
sheet  concept,  a  list  of  key  fleet  attributes  that  can  be  measured  is  developed. 
The  list  is  presented  in  an  accessible,  easy-to-explore  manner  in  the  DSS.  Seven 
attributes  were  chosen  to  represent  the  comparison  of  fleets:  the  annualized  cost 
of  a  fleet,  a  performance  index,  a  flexibility  index,  a  fleet  quality  index,  the 
number  of  aircraft,  the  number  of  major  ships  and  the  number  of  at-sea  officer 
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billets.  Three  of  the  attributes  need  a  brief  explanation.  The  perfornaance  index 
is  the  “value  of  a  multiattribute  utility  model  that  accumulates  measures  of 
effectiveness  values  across  all  major  assets  in  the  fleet"  [Ref.  3:p.  13].  The  fleet 
quality  describes  how  worn  out  the  fleet  is.  The  flexibility  index  measures  the 
range  of  assets  available  in  the  fleet. 

The  DSS  was  designed  for  the  Coast  Guard  in  the  general  area  of  fleet  mix 
planning.  The  authors  indicate  that  their  prototype  DSS  has  met  with  some 
initial  success. 

D.  FLEET  MIX  MODELS 

In  the  past,  the  Coast  Guard  has  used  two  models  for  specific  aspects  of  fleet 
mix  planning.  The  first  predicts  the  performance  of  a  vessel  on  patrol.  The  other 
model  evaluates  the  performance  of  vessels  in  a  SAR  simulation. 

1.  Patrol  Boat  Performance. 

“Predicting  Patrol  Performance"  [Ref.  7]  presents  an  approach  using  a 
Markov  model  for  predicting  the  performance  of  a  vessel  of  patrol.  The  author 
presents  a  classification  of  the  patrol  activities  of  a  vessel  and  a  list  of 
characteristics  important  for  modeling  patrol  boat  capabilities. 

2.  SAR  Simulation 

The  “Search  and  Rescue  Monte  Carlo  Simulation"  [Ref  8:p.  15]  uses  a 
simulation  approach  to  measure  the  effectiveness  of  various  types  of  proposed 
patrol  boat  designs  in  a  SAR  situation.  The  authors  include  salient  aspects  of  a 
typical  SAR  case  (distance  to  datum,  search,  survival  time  and  weather)  in  their 
model. 
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E.  SOLUTION  APPROACH 

Having  defined  the  problems  in  fleet  mix  planning,  we  present  an  overview 
of  our  approach  here  and  discuss  T  in  more  detail  in  Chapter  HI.  The  DSS  will 
assist  decision  makers  in  developing  and  comparing  arguments  regarding 
alternative  courses  of  action.  The  fleet  mix  alternatives  selected  by  the  user  are 
evaluated  by  the  DSS  in  the  attributes  of  cost,  potential  activity  and  performance. 
Evaluation  results  for  all  fleet  mix  alternatives  are  presented  in  a  common  table, 
allowing  the  user  to  detect  advantages  and  disadvantages  of  one  fleet  mix 
alternative  relative  to  the  others. 

The  performance  measures  for  a  fleet  mix  alternative  will  be  produced  using 
a  computer  simulation.  A  computer  simulation  is  used  to  simulate  a  real  world 
event  or  a  set  of  events,  under  a  controlled  set  of  rules,  and  executes  a  series  of 
action?  that  are  then  measured  for  comparison  [Ref.  5:p.  108].  Specifically,  we 
simulate  a  fleet  of  patrol  boats,  operating  within  a  designated  boundary  (namely 
a  Coast  Guard  district),  and  measure  the  performance  using  a  set  of  randomly 
generated  events.  For  example,  one  of  the  randomly  generated  events  is  a  SAR 
case.  A  Coast  Guard  cutter  will  need  to  respond.  A  cutter  will  be  selected,  and 
set  on  course  to  commence  search  and  rescue  assistance.  Appropriate 
characteristics  of  the  cutter  and  the  event  will  be  measured.  Example  of  these 
characteristics  are:  "time  the  victim  is  ir.  vwii and  "the  fuel  consumed  by  the 
patrol  boat".  This  process  continues  with  random  events  and  responding  patrol 
boats  during  a  simulated  168  hour  week.  The  significant  measures  are  totaled. 
The  Coast  Guard  decision  makers  can  use  these  measures  to  compare  alternative 
fleet  mixes.  Our  DSS  will  not  produce  an  optimal  fleet  mix,  yet  it  will  provide 
the  user  with  valuable  information  for  comparing  alternatives. 
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This  chapter  has  presented  a  view  of  the  complexity  of  the  fleet  mix  planning 
problem  and  some  of  the  factors  that  are  considered  in  the  decision  process.  One 
alternative  solution  approach  to  the  fleet  mix  planning  problem,  and  two  Coast 
Guard  patrol  boat  performance  evaluation  tools  were  discussed.  This  research 
builds  on  the  previous  research,  and  presents  our  DSS  for  fleet  mix  planning. 
Chapter  HI  vsdll  discuss  our  design  for  the  patrol  boat  fleet  mix  planning  DSS. 
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III.  THE  DECISION  SUPPORT  SYSTEM 


This  chapter  presents  our  design  for  the  fleet  mix  planning  decision 
support  system.  We  begin  developing  and  structuring  the  DSS  by  exploring 
four  main  issues  relevant  to  it:  the  application  theory,  the  conceptual 
approach,  the  representations  and  the  operations  of  the  system.  Each  of 
these  areas  will  be  discussed  in  the  first  section  of  this  chapter.  The  second 
section  of  this  chapter  will  examine  and  present  methods  for  evaluating  and 
comparing  fleet  mix  alternatives. 

A.  DSS  DESIGN 

1.  Application  Theory 

The  application  theory  answers  the  question  "What  will  this  system  be 
used  for,  how  can  it  be  useful,  and  why  is  it  needed?"  Broadly,  the  purpose  of 
a  DSS  is  to  assist  decision  makers  regarding  alternative  courses  of  action.  In 
the  context  of  fleet  mix  planning,  what  is  needed  is  a  DSS  that  can  tackle  the 
problem  in  parts.  The  DSS  can  then  be  immediately  useful,  without  having 
to  solve  the  entire  problem.  The  DSS  can  be  enhanced  until  the  problem  is 
sufficiently  solved  or  the  investment  of  time  does  not  add  significant  value. 
This  incremental,  iterative  process  to  the  DSS  approach  will  provide  the 
decision  maker  with  a  system  that  is  of  immediate  use.  It  can  be  expanded  as 
organizational  confidence  grows  and  as  its  results  are  accepted. 

Also,  the  DSS  provides  the  user  valuable  information  about  various 
facets  of  fleet  planning  in  one  easily  accessible  system.  Information  about 
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ships,  costs,  crew  sizes  and  homeport  facilities  will  be  available  through  the 
DSS. 

a.  System  Use 

The  intended  application  of  the  system  can  be  classified  into  three 
broad  categories.  First  the  system  will  provide  features  to  evaluate  various 
characteristics  of  a  fleet  mix  alternative  that  bear  on  the  decision.  Second,  the 
system  will  provide  features  to  create  and  analyze  data  scenarios  to  evaluate 
important  attributes  of  the  fleet  mix  alternative.  A  solution  obtained  from 
analysis  of  many  possibilities  should  account  for  much  of  the  uncertainty  in 
the  environment,  (discussed  in  Chapter  II)  and  should  be  robust  and  less 
sensitive  to  changes.  Third,  we  will  emphasize  system  features  that  allow 
users  to  justify  decisions  that  may  be  reached  on  the  basis  of  these  results. 

b.  Need  for  Decision  Support 

The  primary  goal  of  this  research  is  to  provide  a  tool  that  meets 
existing  needs  in  the  Coast  Guard.  A  listing  of  the  Coast  Guard's  needs  for 
support  in  the  acquisition  process  is  provided  in  [Ref  3:p.  8].  Some  of  those 
needs  are  consistent  with  the  objectives  of  this  research  and  are  quoted 
below: 

•  An  existing  need  to  replace  an  aging  fleet  of  capital  assets. 

•  A  policy  and  political  environment  in  which  funds  are  in  short  supply. 

•  Vessel  acquisitions  are  complex  and  difficult,  and  require  years  of  effort 
and  planning.  (Typically  5-10  years  elapse  between  initiation  of  an 
acquisition  project  and  actual  construction  of  new  assets.  Ships  remain 
among  the  most  complex  of  human  artifacts.) 

•  Complexity  and  difficulty  are  increased  by  new  technology,  changing 
mission  requirements,  and  the  fact  that  fleet  mix  planning  becomes 
more  critical  with  limited  resources. 
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•  Analysis  of  alternatives  has  been  weak  and  previously  done  without 
extensive  management  science  techniques. 

•  Shortage  of  personnel;  existing  personnel  are  overextended  and  must 
answer  many  difficult  questions  from  the  Department  of  Transportation, 
Congress,  etc.  The  Coast  Guard  requires  a  fast,  accurate,  and  consistent 
way  of  responding. 

•  The  costs  of  mistakes  and  vagueness  are  high,  with  the  costs  measured 
in  credibility  with  the  Department  of  Transportation  and  Congress,  and 
in  dollars  paid  to  contractors  for  Coast  Guard  mistakes  and  to  attorneys 
for  litigation  support.  [Ref  3:p.  8-11] 

The  DSS  provides  decision  makers  with  a  tool  that  will  facilitate  the 
evaluation  of  fleet  mix  alternatives.  It  will  have  the  ability  to  perform  ad  hoc 
queries  on  data  about  fleet  mixes.  In  addition,  the  DSS  breaks  the  complex 
fleet  mix  problem  into  manageable  and  understandable  parts  for  the  user. 

2.  Conceptual  Approach 

We  have  discussed  the  application  theory  of  the  DSS  in  the  above 
paragraphs.  To  help  clarify  and  illustrate  how  the  system  should  be  delivered 
and  what  the  system  should  look  like,  we  discuss  the  conceptual  approach 

underlying  our  system.  Our  conceptual  approach  will  be  to: 

•  develop  a  set  of  measurable  key  characteristics  of  a  fleet  mix. 

•  group  the  characteristic  measures  into  the  three  primary  measures:  cost 
measures  of  a  fleet  mix  alternative,  activity  measures  of  a  fleet  mix 
alternative,  and  performance  measures  of  a  flee^  mix. 

•  present  the  characteristic  measures  in  a  hierar  ^..al  environment  that 
uses  a  hypertext  presentation  system  [Ref  9:p.  3-8]. 

The  three  types  of  measures  entail:  a)  cost  measures  that  will  be 
provided  by  the  Coast  Guard,  b)  activity  measures  that  will  also  be  primarily 
provided  by  the  Coast  Guard,  and  c)  performance  measures  that  produced 
using  the  simulation  model  developed  in  our  DSS. 
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3.  Representations 

The  DSS  is  able  to  represent  a  diverse  set  of  information  such  as 
cutters,  homeports  and  events.  In  particular,  the  following  items  will  need  to 

be  represented  in  the  system. 

•  Characteristics  of  a  ship. 

•  Homeport  pier  facilities  and  location. 

•  Coast  Guard  Districts. 

•  Components  of  a  fleet  mix. 

•  Characteristics  of  an  event. 

•  Simulation  inputs. 

•  Rules^  about  dispatching  cutters  to  a  mission. 

•  Models  and  formulas. 

The  DSS  will  provide  internal  and  external  representations  in  order  to 
capture  the  information  required. 

a.  Internal  Representations 

The  internal  representations  of  the  DSS  will  include  data  structures 
and  rules  in  the  knowledge  base.  In  particular,  relational  data  tables  will  be 
used  to  store  data  about  the  ships,  homeports,  pier  facilities,  districts,  events, 
and  fleet  mixes.  A  model  base  will  be  used  to  store  the  rules  and  models 
required  by  the  DSS. 

b.  External  Representations 

The  external  representations  of  the  DSS  will  include  data  entry 
forms,  tabular  reports,  icons  and  buttons  in  a  hypertext  environment.  Data 


5Rules  are  used  to  represent  the  logic  required  to  take  actions  such  as 
assigning  ships  to  events.  Rules  decide  the  proper  action  to  take  when  an 
event  is  called  and  executed. 
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entry  forms  will  be  used  to  allow  the  user  to  input  the  data  required  about  a 
new  ship,  a  fleet  mix,  and  a  simulation  run.  Tabular  reports  will  be  used  to 
display  simulation  results,  fleet  mixes,  homeports  in  a  district,  and 
simulation  inputs.  Icons  will  be  used  to  represent  types  of  ships  and  events. 
Buttons  will  be  used  to  represent  navigational  commands,  start-up 
commands  and  execution  commands. 

4.  Operations 

Operations  on  the  information  structures  are  supported  by  the 
following  user  capabilities. 

•  Perform  simulations  on  selected  fleet  mixes  and  scenarios. 

•  Aggregate  simulation  results. 

•  Present  the  results  in  a  final  results  format. 

•  Create  a  new  ship,  an  alternative  fleet  mix,  or  a  scenario. 

•  Modify  ship  characteristics,  homeports,  districts,  fleet  mixes, 
performance  tempo,  and  sea  state  conditions. 

•  Print  reports  as  required:  Simulation  results.  Cost  and  Performance 
Measures,  and  data  retrieved  from  a  database. 

In  summary,  we  have  defined  the  four  main  issues  relevant  to  the 
development  and  structure  of  the  DSS.  This  section  also  discussed  what  the 
user  will  use  and  see  in  the  DSS.  In  the  following  section,  the  emphasis  shifts 
to  the  functionality  of  the  DSS  and  how  the  system  will  achieve  the  items 
discussed  above. 

B.  FLEET  MIX  EVALUATION 

The  DSS  provides  results  for  alternative  fleet  mixes  in  three  significant 
attributes.  The  first  attribute  is  the  cost  of  the  fleet  mix.  The  second  is  the 
potential  activity  of  the  fleet  mix.  The  third  is  the  performance  of  the  fleet 
mix. 
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1.  Lifecycle  Cost 

The  OMB  Circular  A-109  requires  an  analysis  of  the  lifecycle  cost  of  a 
proposed  patrol  boat  capability  replacement  [Ref.  10:p.  4-14].  The  lifecycle  cost 
for  the  fleet  of  patrol  boats  is  more  difficult  to  define,  since  some  patrol  boats 
are  nearing  the  end  of  their  service  life,  some  are  new,  and  some  have  not 
been  built  yet.  The  lifecycle  cost  for  one  vessel  is  the  sum  of  the  costs  in  the 
following  categories: 

•  Ownership  costs  include  acquisition  cost,  mid-life  refurbishment  costs, 
and  salvage  /disposal  costs. 

•  Operating  costs  include  fuel,  oil,  lubricants  and  hotel  costs  (food, 
blankets). 

•  Maintenance  costs  include  preventive  and  corrective  maintenance  costs. 

•  Personnel  costs  include  the  standard  billet  costs  for  the  assigned  crew 
and  designated  support  personnel.  [Ref.  11] 

These  costs  are  distributed  throughout  the  service  life  of  the  vessel.  To 
provide  a  means  of  comparing  alternatives,  the  present  value  of  the  cost  is 
computed  using  discount  factors  and  is  called  the  lifecycle  cost.  The 
annualized  lifecycle  cost  is  the  uniform  annual  payment  over  the  service  life 
of  the  vessel  equivalent  to  the  lifecycle  cost.  The  DSS  computes  the  total  of 
the  annualized  lifecycle  costs  for  the  fleet  mix  alternative. 

The  individual  components  for  the  cost  attribute  within  the  current 
version  of  the  DSS  will  be  entered  by  the  Coast  Guard  users.  A  spreadsheet 
application  is  planned  for  computation  of  the  lifecycle  cost.  The  values  for 
cost  in  each  category  and  the  timing  of  the  cost  will  be  entered  by  the  user. 

2.  Activity 

The  attribute  of  potential  activity  relates  to  the  time  available  during  a 
year  for  each  of  the  patrol  boat's  required  tasks.  These  activities  include 
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maintenance,  standby,  patrol  and  crew  rest.  The  user  can  enter  and  modify 
numbers  in  each  category  for  a  specific  class  patrol  boat.  The  DSS  computes 
the  activity  for  the  entire  fleet  mix  alternative. 

3.  Performance 

Our  approach  evaluates  performance  using  a  computer  simulation. 
The  method  measures  performance  of  a  fleet  mix  of  cutters  in  a  situation  that 
simulates  the  operating  environment  for  the  patrol  boats.  The  basic  idea  of 
the  simulation  approach  is  simple.  Each  alternative  fleet  mix  is  evaluated 
under  a  scenario  representing  a  fragment  of  real-life  demand  on  the  Coast 
Guard's  fleet.  This  evaluation  is  performed  by  simulating  responses  to 
random  events,  and  measuring  the  costs  and  performance  of  the  results  of 
these  responses.  By  repeating  this  evaluation  over  a  variety  of  scenarios  that 
could  represent  future  demand  (given  the  information  known  today),  these 
results  will  represent  a  robust  and  fair  evaluation  of  the  fleet  mix.  By 
evaluating  each  fleet  mix  under  the  same  set  of  scenarios,  we  can  get  a 
comparative  evaluation  of  the  alternative  fleet  mixes. 

Several  models  are  needed  within  the  simulation  process.  These  are 
an  event  manager  for  random  event  generation,  a  dispatch  model  for 
selecting  the  cutter  to  send  on  a  mission,  an  intercept  model  to  compute  the 
dispatched  patrol  boat's  course  in  order  to  intercept  a  suspected  vessel,  a  ship 
movement  model  to  update  each  ship's  position  at  each  interval  and  an 
operations  manager  to  control  changes  to  a  vessel's  assignment. 

a.  Event  Manager  Model 

The  event  manager  determines  if  an  event  occurs  during  a  time 
interval.  First,  the  model  generates  a  random  number.  If  the  number  falls 
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within  a  certain  range,  no  event  occurs.  If  the  number  is  in  another  range  an 
event  occurs.  A  second  random  number  is  used  to  select  the  type  of  event,  its 
location  and  other  event  details.  The  details  for  the  events  are  drawn  from  a 
table  of  typical  patrol  boat  events  such  as  SAR  cases  and  drug  boat  traffic. 

b.  Dispatch  Model 

The  dispatch  model  uses  information  about  the  most  recent  event 
to  assign  the  appropriate  cutter  to  the  case.  The  location  of  the  event  (such  as 
a  ship  in  distress)  and  the  type  of  event  are  the  key  variables.  This  model  was 
developed  through  interviews  with  various  Coast  Guard  officers.  The  event 
manager  first  makes  a  list  of  patrol  boats  available  for  assignment  to  the 
mission.  The  SAR  mission  has  the  highest  priority,  and  a  vessel  could  be 
diverted  from  another  lower  priority  mission  if  necessary.  Patrol  boats  in  the 
standby  condition  (inport)  will  be  directed  to  respond  if  required.  Patrol  boats 
are  not  considered  if  they  have  insufficient  fuel  or  are  due  to  complete  a 
patrol  within  a  day.  In  the  case  of  a  moving  target,  the  vessel  that  is  in  the 
best  position  to  intercept  the  moving  vessel  (normally  a  drug  boat)  is 
assigned.  In  the  case  of  SAR,  the  vessel  that  can  get  to  the  scene  first  is 
assigned  to  a  SAR  case.  Other  types  of  missions  are  assigned  to  the  closest 
vessel  with  the  capability. 

c.  Intercept  Model 

The  intercept  model  uses  information  about  the  location,  course 
and  speed  of  the  vessel  to  be  intercepted,  the  location,  and  maximum  speed 
information  of  the  patrol  boats  eligible  for  assignment.  Typical  geometry  of 
the  situation  is  shown  in  Figure  3-1.  The  position  of  ships  is  indicated  by  x 
and  y  coordinates  on  a  grid  representing  the  Coast  Guard  district.  The  goal  is 
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to  select  the  cutter  that  is  in  the  best  position  to  intercept  the  drug  boat,  and 
compute  an  intercept  course  for  the  selected  cutter.  The  problem  is  solved 
using  the  following  steps. 

•  Assumptions:  The  computations  assume  the  position  of  both  vessels 
are  known,  the  target  vessel  course  and  speed  are  known,  and  that  the 
target  doesn't  change  either  course  or  speed.  In  reality  if  target  course  or 
speed  changed,  the  patrol  boat  would  compute  a  new  intercept  course. 

•  The  basic  approach  to  finding  the  intercept  course  relies  on  a  line-of- 
sight  diagram  (Figure  3-  2).  The  distance  to  the  target  vessel  and  the 
bearing  to  the  target  vessel  is  determined.  The  target  course  is  plotted  on 
the  upper  end  of  the  diagram,  and  the  speed  is  indicated.  The  target  has 
speed  across  the  line-of-sight  and  speed  in  the  line  of  sight.  By  selecting  a 
course  for  the  patrol  boat  that  has  the  same  speed  across  the  line-of-sight, 
the  patrol  boat  will  achieve  the  fastest  intercept  of  the  target  vessel.  Note 
that  some  of  the  patrol  boat  speed  will  be  in  the  line-of-sight,  tending  to 
reduce  the  range  to  the  target.  The  process  is  illustrated  below. 


1 

Figure  3-1  Geometry  of  Target  Intercept. 
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Figure  3-2  The  Line-of-Sight  Diagram  for  Determining  Intercept  Course. 

•  Compute  the  range  between  the  vessels. 

Range  =  VjX^  -  -  y,j2 

•  Compute  the  bearing  to  the  target  vessel. 


Bearing  =  90  -  arcsin 


Vt-Vp 


^Range^ 
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•  Compute  the  angle  (a)  between  the  target  course  and  the  line-of-sight. 
This  angle  will  be  used  to  compute  the  target  speed  across  (perpendicular 
to)  the  line-of-sight  and  speed  in  the  direction  of  the  line-of-sight. 


a  =  180 -{Target_course  -  Bear ing _to  _tar get) 


•  Compute  the  target  speed  across  the  line-of-sight. 


Speed  jacr OSS _LOS  =  Target_Speed  x  Sin  a 


•  Compute  the  angle  (P)  between  the  line-of-sight  and  the  patrol  boat 
course.  This  course  is  selected  to  have  the  same  speed  across  the  line-of- 
sight  as  the  target  vessel.  The  other  condition  for  the  course  is  that  it  be 
closing  the  target  rather  than  opening. 


PatrolJjoatjspeed  x  sin  P=  Target_speed  x  sin  a 
P  =  Arcsin|^°-'^g^ 


Patrol  _boat_Speed 


•  Compute  the  patrol  boat  course.  There  are  two  cases:  either  a  target 
course  on  the  left  side  of  the  line-of-sight  (port)  as  shown  in  Figure  3-2  or 
the  target  course  on  the  right  side  of  the  LOS  (STBD). 


For  a  Port  LOS:  Patrol Jboatjcourse  =  Bearing_to_target  -  /? 
For  a  STBD  LOS:  Patrol _boat_course  =Bearing_to_target  +  p 


•  The  time  to  interception  is  computed.  Again  there  are  two  cases:  If  the 
target  is  opening  (we  see  his  stern),  the  speed  components  subtract.  The 
patrol  boat  will  be  chasing  the  target.  The  second  case  is  a  closing  target 
(we  see  his  bow)as  illustrated  in  Figure  3-2,  and  the  speeds  add  as  shown 
below. 
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Relative _speed_in_the  LOS  =  Target_speed  x  cos  a  +  Patrol _boat_speed  x  cos  P 

Range 

Time_to_intercept  =  — : - - - f - ; — ,  ^  ^ 

Relative_Speed_tn_the_L  O  S 

The  intercept  model  computes  the  time  to  intercept  for  each  patrol 
boat  that  is  eligible  for  assignment.  The  patrol  boat  with  the  minimum 
intercept  time  probably  will  have  the  best  opportunity  and  geographic 
position  to  intercept  the  target  and  perform  the  mission.  Other  patrol  boats 
could  have  a  very  long  intercept  time  if  they  are  chasing  the  target  from 
behind.  The  boat  with  the  minimum  intercept  time  is  assigned  to  the 
mission,  its  speed  is  changed  to  maximum  and  it'  course  is  set  to  the  intercept 
course. 

d.  Ship  Movement  Model 

The  ship  movement  model  computes  a  new  position  each  interval 
for  any  vessel  (patrol  boats  and  drug  boats)  based  on  its  assigned  course,  speed, 
and  the  previous  position.  The  positions  are  computed  using  the  following 
relationships: 

X2  =  Xi  +(x.  component _  of  _speed  x  Time) 

X2  =  X]  +  Cos(90  -  Vessel _course)  x  {V essel _speed  )  x  T 

y2  =  Yi  +  Sin(90  -  V essel jcourse)  x  {V essel _speed  )  x  T 

•  where  T  is  the  time  interval  (one  hour) 

•  (90  -  Vesseljcourse  )  is  the  conversion  of  the  vessel's  course  measured 
in  degrees  relative  to  north  to  an  angle  relative  to  the  X  axis  as  shown  in 
the  Figure  3-3  below. 
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Figure  3-3  Geometry  of  Vessel  Motion. 
e.  Ship  Operations  Manager 

Some  situations  will  require  a  change  in  the  patrol  boats  operating 
conditions.  The  dispatch  and  intercept  models  make  changes  to  course  and 
speed  in  response  to  a  new  mission.  The  ship  op  -rations  model  makes 
changes  in  all  other  conditions.  Some  of  these  conditions  are  that  the  patrol 
boat  is  low  on  fuel  and  must  refuel,  or  that  the  patrol  boat  has  completed  its 
patrol  and  returns  to  port,  or  the  patrol  boat  reaches  it's  destination  and  must 
slow  to  render  aid.  The  need  for  change  is  normally  detected  by  the  ship 
movement  model,  as  it  routinely  checks  the  quantity  of  fuel  remaining,  days 
underway  and  the  distance  remaining  to  the  destination.  When  the  ship 
operations  model  is  called,  a  parameter  is  set  to  indicate  tne  prerent  condition 
and  the  change  necessary. 
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We  have  discussed  the  design  of  the  DSS  and  the  methods  for  evaluating 
fleet  mix  performance  using  the  DSS.  Chapter  IV  presents  our 
implementation  of  this  design  in  an  operational  DSS  prototype. 
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IV.  IMPLEMENTATION  OF  FELIX 


The  system  design  described  in  Chapter  III  has  been  implemented  in  a 
prototype  DSS  called  Felix.  This  chapter  presents  the  implementation  process 
of  the  DSS  and  highlights  the  major  components  of  the  system.  In  addition, 
transfer  of  data  and  control  between  three  different  software  products  is 
discussed.  A  brief  description  of  the  hardware  and  software  selected  for  the 
implementation  of  the  DSS  is  first  introduced. 

Initial  requirements  for  Felix  were  that  the  user  interface  be  built  with  a 
hypermedia  software  application,  and  that  a  relational  type  database  be  used. 
Felix  is  implemented  and  runs  on  the  Macintosh®  II  family  of  machines 
with  eight  megabytes  of  random  access  memory.  The  database  was  developed 
using  a  relational  DBMS  labeled  ORACLE®  (version  1.2  published  by  Oracle 
Corporation),  the  interface  was  developed  using  SuperCard®  (version  1.5 
developed  by  Silicon  Beach  Software),  and  the  model  base  was  developed 
with  Nexpert  Object®  (version  2.0  published  by  Neuron  Data). 

A.  APPLICATION  INTERFACES 

Ensuring  that  all  three  products  could  commi  '  /ite  with  each  other  was 
the  most  important  factor  in  the  selection  process.  Oracle  is  a  relational 
database  that  is  specifically  designed  to  take  advantage  of  a  hypermedia 
software  application.  SuperCard  is  a  newly  developed  hypermedia  software 
that  advances  the  original  HyperCard®  environment  made  famous  by 
Apple®.  Nexpert  is  an  expert  system  shell  that  provides  interfaces  for 
several  of  the  well  known  software  products.  We  will  briefly  discuss  how 
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each  software  package  communicates  with  the  other  two  and  how  they 
provide  the  interface  process  that  is  required  for  the  implementation  of  Felix. 

1.  Oracle 

Oracle  databases  are  managed  by  the  Oracle  Relational  Database 
Management  System  (RDBMS).  The  data  within  the  tables  is  accessed  by  using 
commands  issued  in  Structured  Query  Language^  (SQL).  Oracle  provides 
additional  features  to  interface  with  other  software  applications.  The  two 
features  required  to  interface  with  SuperCard  and  Nexpert  are  addressed 
below. 

a.  Hyper*SQL 

Hyper’^QL  is  an  Oracle  application  which  allows  the  database  tables 
to  be  accessed  from  a  hypermedia  software  application,  such  as  SuperCard. 
The  access  commands  (initiated  from  SuperCard)  allow  the  user  to  initiate 
Oracle  database  operations,  such  as  starting  and  stopping  Oracle,  logging  on  to 
a  database,  creating  database  objects,  performing  queries,  inserting  and 
updating  data,  and  monitoring  error  and  control  messages  through 
Hyper’^QL  scripts^  [Ref.  12;p.  4-1]. 

b.  Pro*C 

Pro*C  provides  an  environment  in  which  the  user  can  use  a  C 
language  application  (such  as  Nexpert)  to  access  the  database  tables.  The  C 


^SQL  is  an  English-like,  non-procedural  language  defined  by  IBM™ 
Research  and  introduced  to  the  commercial  market  in  1979. 

7A  script  is  basically  an  informal  small  computer  program  written  in  the 
appropriate  language  that  executes  whenever  the  user  takes  some  action.  For 
example,  the  user  may  click  a  mouse  button  or  select  a  command  from  a 
menu  to  commence  an  action. 
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language  program  is  translated  by  the  Pro*C  precompiler  into  equivalent  SQL 

commands.  Some  of  the  features  of  the  Pro*C  precompiler  are: 

•  Each  SQL  statement  is  automatically  translated  to  the  equivalent 
runtime  library  calls,  reducing  programming  time. 

•  A  single  Pro*C  program  can  be  created  to  operate  with  data  from 
different  Oracle  databases. 

•  Multiple  Pro’^C  programs  can  be  separately  precompiled  and  executed 
together  in  the  same  application  [Ref.  12:p.  9-1]. 

2.  SuperCard 

SuperCard  uses  a  scripting  language  called  SuperTalk  to  perform 
internal  operations.  An  external  command  facility  (XCMD)  allows  developers 
to  write  SuperCard  applications  that  communicate  with  external  programs 
including  Oracle  and  Nexpert  [Ref.  9:p.  145-147]. 

a.  XCMD  for  Oracle 

When  SuperCard  encounters  the  external  command  EXECSQL  in  a 
script,  the  remaining  program  line  is  passed  from  SuperCard  to  Oracle 
through  the  Hyper*SQL  interface.  An  example  of  an  EXECSQL  command 
embedded  in  a  script  would  be:  "EXECSQL  Select  SEQUENCE  from 
SIMULATION_QUEUE." 

b.  XCMD  for  Nexpert 

SuperCard  has  two  way  communications  with  Nexpert  by  using  the 
external  command  NXP.  In  addition,  the  Nexpert  Dynamic  Library  (NDL)  and 
the  Nexpert  Handler  Interface  (NHI)  files  must  be  installed  in  the  System 
folder.  NDL  provides  access  to  the  system  features  of  Nexpert  from  other 
programs  and  the  file  NHI  is  the  file  that  passes  message  between  SuperCard 
and  Nexpert. 
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3.  Nexpert 

Nexpert  provides  the  developer  several  flexible  methods  for 
communication  with  external  programs  and  databases.  The  Nexpert  Database 
bridge  and  HyperBridge  provide  an  easy  interface  to  Nexpert  compatible 
applications.  The  database  bridge  supports  a  wide  variety  of  file  and  database 
formats  but  we  will  discuss  only  the  process  for  linking  Nexpert  with  Oracle 
[Ref.  13].  The  Nexpert  HyperBridge  consists  of  several  modules  which  enable 
the  Nexpert  Dynamic  Library  to  be  accessed  directly  from  SuperCard  scripts 
using  XCMD  commands  [Ref.  14:p.  1-20]. 

a.  Database  Bridge 

The  Nexpert  Database  bridge  is  invoked  when  Nexpert  processes  a 
Retrieve  or  Write  command.  The  Retrieve  command  moves  data  from 
Oracle  into  Nexpert's  working  memory,  the  Write  command  moves  data 
from  Nexpert's  working  memory  to  Oracle.  The  bridge  does  much  more  than 
simply  transfer  data;  it  also  transforms  it  between  Nexpert's  class-object- 
property  representation  and  Oracle's  format  [Ref.  13:p.  57].  The  specific 
implementation  process  can  be  found  in  the  Nexpert  Object  Version  2.0 
Database  Integration  Guide.  Briefly,  the  implementation  process  uses  the 
Nexpert  Database  Editor  to  list  the  available  database  interfaces  already  built 
into  Nexpert.  The  keyword  ORACLE  is  used  by  Nexpert  to  designate  an  Oracle 
database.  The  keyword  is  used  before  each  call  to  the  appropriate  database. 

b.  Nexpert  HyperBridge 

The  Nexpert  HyperBridge  integrates  Nexpert  to  other  applications 
through  its  runtime  library.  The  Nexpert  Handler  Interface  (NHI)  is  the 
interface  from  Nexpert  to  the  SuperCard  script.  This  handler  is  used  to  return 
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messages  to  SuperCard.  The  NDL  receives  the  NHI  message  and  translates 
the  message  into  the  proper  code  for  use  by  SuperCard. 

The  interfaces  between  programs  are  an  important  part  of 
developing  any  program  and  was  a  critical  one  in  the  success  of  Felix.  We 
have  introduced  the  intricate  process  of  connecting  the  three  programs 
selected  in  building  our  DSS.  Specific  details  of  each  were  omitted  but  the 
important  interface  commands  were  briefly  discussed.  In  the  following 
section,  we  present  the  modules  within  Felix. 

B.  FELIX  MODULES 

Felix  is  implemented  in  three  components  that  are  directly  related  with 
the  three  selected  software  products.  The  first  component  is  the  Oracle 
database.  The  second  component  is  the  user  interface  that  was  developed 
with  SuperCard.  The  third  component  is  the  model  (including  math  and 
deductive  models)  base,  developed  in  Nexpert.  Figure  4-1  illustrates  the 
design  of  Felix.  In  this  system,  the  user  will  work  directly  with  the  user 
interface.  The  user  interface  will  access  the  DBMS  and  knowledge  base  as 
required  by  the  user.  The  DBMS  will  access  ihe  appropriate  data  files  in 
storage.  The  knowledge  base  will  access  the  models,  objects  and  rules  as 
needed  to  complete  the  task  requested  by  the  user.  In  addition,  the  knowledge 
base  may  require  a  data  file  and  will  access  the  DBMS.  Each  of  these  three 
components  has  several  interface  modules  that  complete  separate  tasks 
within  the  component.  We  explain  each  component’s  internal  modules  and 
its  external  relationship  with  the  other  two  major  components  in  the 
following  paragraphs. 
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Figtire  4-1  Configuration  Layout  of  FELIX 
1.  Oracle  Database 


The  database  management  system  (DBMS)  consists  of  a  database  with 
data  tables  that  store  the  DSS  data.  The  database  is  the  passive  component  in 
the  system.  It  only  provides  a  data  repository  service  to  the  oiiier  components. 
Figure  4-2  illustrates  the  external  relationships  with  the  user  interface  and  the 
model  base,  and  the  internal  modules. 
a.  External  Relationships 

The  tables  stored  in  the  database  are  used  by  the  user  interface  and 
the  model  base.  For  example,  the  model  base  requests  values  from  a  table 
stored  in  Oracle  and  uses  that  data  as  inputs  to  a  model  or  rule.  Afterwards, 
the  outpuk  da' a  of  the  process  is  transferred  to  the  database  for  storage.  The 
relationship  with  the  user  interface  is  similar.  The  user  requests  information 
from  the  database.  The  data  is  transferred  and  returned  to  storage  upon 
completion. 
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Figure  4-2  DBMS  Layout  Design. 


b.  Internal  Modules 

The  da^a  within  the  database  is  classified  into  two  general  groups. 
Fleet  Mix  data  and  Evaluation  data,  each  of  them  having  several  tables.  In  the 
Fleet  Mix  data  group,  the  tables  include  data  that  pertain  to  the  Coast  Guard 

cutters.  Examples  of  these  data  tables  are: 

•  Cutter  Characteristics  Table:  Captures  important  data  about  a  specified 
cutter,  including  Max  Speed,  Length,  Beam,  ar  ,  3veral  others. 

•  Fleet  Mix  Tables:  Captures  the  type  and  quantity  of  cutters  that  comprise 
the  specified  fleet  mix,  including  WPB-80's,  WPB-82's,  WPB-llO's  and 
WPB-120's. 

•  Homeports  Table:  Captures  the  data  required  to  identify  the  location  and 
facilities  of  a  homeport,  including  the  City,  State,  District,  Restrictions, 
and  Limitations. 
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In  the  Evaluation  data  grouping,  the  tables  store  required  data 
needed  to  run  the  evaluation  process  and  the  results  from  an  evaluation. 

Examples  of  this  type  of  data  are: 

•  Simulation  Queue  Table:  Captures  information  about  the  next 
simulation  to  run,  including  Fleet  Mix  selected.  District,  Sea  State,  Sea 
State  Trend  and  Operation  Tempo. 

•  Events  Table:  Captures  information  about  six  different  possible  events 
that  could  occur  in  a  simulation  rim. 

•  Simulation  Results  Table:  Captures  information  about  the  results  of  the 
simulation,  including  SAR  Missions,  ELT  missions.  Failed  SAR 
Missions  and  several  others. 

2.  User  Interface 

The  Felix  user  interface  is  an  interactive  system  designed  to  allow  the 
user  to  quickly  master  Felix.  The  primary  design  goals  are  to  provide  the  user 
a  friendly  easy  system  and  to  provide  a  system  that  can  be  easily  enhanced  as 
the  need  arises  [Ref.l5:p.  9].  In  our  first  goal,  we  refer  to  the  user  interactions 
with  the  tasks  and  sub-tasks  that  must  be  carried  out  within  Felix.  Task 
functionality  is  centralized  so  that  the  user  can  quickly  return  to  a  familiar 
section  of  Felix  (mainly  the  main  menu).  Excessive  functionality  is  kept  to  a 
minimum  so  as  not  to  confuse  or  frustrate  the  user.  The  screens  presented  to 
the  user  are  similar  and  consistent  in  format  and  enhance  the  user’s  comfort 
with  Felix  as  he  quickly  masters  the  program.  The  second  goal  of  ensuring 
adaptability  of  the  system  refers  to  the  quest  for  a  modular  design  and  correct 
performance. 

The  user  interface  design  is  displayed  in  Figure  4-3.  The  external 
relationships  will  be  discussed  in  the  next  paragraph,  followed  by  the  internal 
modules  of  the  user  interface. 


39 


a.  External  Relationships 

The  external  relationship  of  the  interface  with  the  DBMS  is  sin:\ilar 
to  the  data  transfer  process  discussed  in  the  previous  section.  The  user 
interface  calls  a  table  from  the  DBMS  for  the  user  to  view,  print  or  modify.  In 
addition,  the  user  interface  transfers  new  data  to  the  DBMS  as  created  by  the 
user.  The  data  could  be  from  any  of  the  tables  within  the  database. 

The  external  relationship  with  the  model  base  is  a  program  control 
transfer.  The  call  to  the  model  base  will  relinquish  control  of  the  system  to 
the  Nexpert  program.  The  model  base  returns  control  to  the  user  interface 
upon  completion  of  the  called  evaluation  process. 

b.  Internal  Modules 

Within  the  user  interface  there  are  four  modules:  the  Online  Help 
system,  the  Data  Retrieval/Insertion/Update  module,  the  Report  Generator, 
and  the  Model  Base  Control.  The  four  modules  are  briefly  discussed  below. 

The  Online  Help  System  is  found  on  each  of  the  display  screens 
within  the  user  interface.  The  user  can  obtain  additional  help  information  by 
pressing  the  Help  button  provided  at  the  bottom  left  corner  of  each  screen.  A 
scrolling  window  will  appear  containing  information  that  explains  each 
option  available  on  the  displayed  card.  An  additional  feature  of  the  Online 
Help  system  is  the  presence  of  additional  bottom  row  buttons  that  provide  the 
user  with  an  easy  method  of  returning  to  the  main  menu. 

The  Data  Retrieval/Insertion/Update  module  allows  the  user  to 
retrieve  the  tables  within  the  database  and  modify  them  as  necessary. 
Additions,  deletions  and  changes  are  common  requirements  in  any  system. 
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and  are  easily  performed  in  Felix.  Additional  features  of  this  module  are  the 
Start/ Stop  buttons  for  Oracle  and  the  Oracle  Log  On  process. 
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Figure  4-3  The  User  Interface  Layout. 


The  Report  Generator  provides  the  user  with  the  ability  to  print 

different  reports.  Examples  of  the  items  available  for  printing  are: 

•  Aggregate  Fleet  Results:  The  report  that  lists  the  final  measures  to  be 
used  by  the  decision  maker. 

•  Homeports:  A  list  of  all  the  homeports  used  by  the  Coast  Guard  and  the 
facility  limitations. 

•  Fleet  Mix:  A  list  of  the  select  fleet  with  information  about  the  vessels 
and  homeport  placement. 

•  Simulation  Result:  List  the  measures  of  a  single  simulation  run. 

The  Model  Base  Control  provides  the  user  the  ability  to  initialize 
Nexpert  and  select  the  evaluation  process.  The  evaluation  process  is  started 
when  the  user  selects  a  button  on  the  Model  Base  Control  card.  The  user 
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initiates  fleet  performance  evaluation  by  selecting  the  Perform  Simulation 
button.  Similarly,  the  user  initiates  aggregate  results  of  performance 
simulations  by  selecting  the  Aggregate  Results  button.  Buttons  are  provided 
for  Evaluate  Costs  and  Evaluate  Activity,  but  this  feature  was  not  provided  in 
the  initial  prototype  version. 

3.  Felix  Model  Base 

The  model  base  for  the  DSS  provides  two  types  of  environments  for 
knowledge  based  applications:  the  development  environment  and  the 
Nexpert  Dynamic  Library.  The  development  environment  is  the  more 
powerful  of  the  two  and  is  used  to  build  and  modify  new  applications.  These 
applications  are  stored  as  individual  program  files  to  be  accessed  as  required. 
The  development  environment  also  provides  templates  for  defining  rules, 
classes,  and  objects.  In  addition,  it  provides  the  knowledge  processing 
function  that  can  be  controlled  step-by-step  if  necessary  for  testing.  In 
comparison,  the  Nexpert  Dynamic  Library  provides  access  to  the  knowledge 
processing  features  of  Nexpert,  but  does  not  provide  the  editing  features. 

Nexpert  uses  rules  to  represent  intelligence,  and  objects  to  represent 
entities  in  the  real  world.  The  logic  of  the  model  is  written  using  rules  that 
reference  objects  such  as  patrol  boats  and  object  properties  such  as  speed  of  the 
patrol  boat.  The  logic  for  the  models  in  the  model  base  was  presented  in 
Chapter  HI. 

The  model  base  in  Felix,  illustrated  in  Figure  4-4,  is  a  Nexpert 
application  with  a  knowledge  base  file  for  each  evaluation  process.  The  user 
interface  calls  the  Nexpert  Dynamic  Library  to  perform  evaluation  of  the  fleet 
mix  using  the  proper  knowledge  base  file.  The  external  relationships  section 
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describes  the  purpose  of  the  model  base  and  its  place  within  the  DSS.  The 
internal  modules  section  describes  the  operation  of  the  models  within  the 
model  base. 

a.  External  Relationships 

The  model  base  is  called  by  the  user  interface  to  perform  various 
types  of  fleet  mix  evaluation  and  analysis.  These  calls  are  basically  program 
control  calls.  Control  of  Felix  is  relinquished  by  the  user  interface  and  is  given 
to  Nexpert  as  the  selected  evaluation  is  being  processed.  Upon  completion, 
control  is  returned  to  the  user  interface. 

The  relationship  of  the  model  base  with  the  database  is  a  basic  data 
transfer.  The  models  retrieve  data  from  the  database  and  write  data  to  the 
database  as  required  for  analysis.  This  process  is  controlled  by  rules  within 
Nexpert. 

b.  Internal  Modules 

The  internal  logic  of  the  evaluation  modules  was  presented  in 
Chapter  III.  Specific  aspects  of  the  model  base  implementation  are  discussed 
below.  The  simulation  and  aggregation  models  are  written  using  Nexpert 
and  are  stored  as  a  Nexpert  knowledge  base.  The  activity  and  cost  modules, 
although  not  implemented,  are  included  for  discussion. 

The  simulation  model  is  called  by  the  user  interface  and  performs 

the  following  steps: 

•  Read  in  simulation  data 

•  Read  in  fleet  mix  data 

•  Read  in  Event  data 

•  Perform  the  first  simulation  run 

•  Write  results  to  the  simulation  results  table. 


43 


•  Repeat  the  above  process  until  all  runs  in  the  simulation  queue  have 
been  performed.  Nexpert  returns  execution  control  back  to  the  user 
interface. 

The  result  aggregation  module  is  also  called  from  the  Model  base 
control  card  in  the  user  interface.  The  aggregation  p?rforms  the  following 
steps: 

•  Read  in  the  data  for  the  fleet  mix  being  aggregated. 

•  The  simulation  results  are  first  combined  by  district. 

•  The  district  results  are  then  combined  for  a  fleet. 

•  Upon  completion,  the  results  are  stored  in  the  database  and  program 
control  is  passed  to  the  user  interface. 


Figure  4-4  The  Model  Base. 

The  activity  module  will  evaluate  the  measures  that  would 
determine  if  the  fleet  could  meet  the  projected  modes  of  operation.  The 
evaluation  process  will  include  assessing  maintenance  hours,  patrol  hours. 


44 


crew  relief  hours,  and  stand-down  hours.  The  focus  will  be  to  analyze  the 
extent  to  which  a  selected  fleet  mix  can  provide  the  required  hours  for  each 
phase  of  a  cutter's  lifecycle. 

The  costs  module  will  evaluate  the  costs  associated  with  a  fleet  mix. 
Some  of  these  costs  include  lifecycle,  acquisition,  operations  and  maintenance 
(O&M),  and  manning. 

This  chapter  has  presented  a  description  of  the  DSS  prototype 
developed  as  a  part  of  this  research.  The  application  interfaces,  user  interface, 
database  and  the  model  base  were  described.  The  next  chapter  will  present  a 
user's  point  of  view  and  will  examine  the  results  of  a  sample  simulation. 
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V.  FLEET  MIX  ANALYSIS  USING  FELIX 


The  procedures  for  using  Felix  to  evaluate  alternative  fleet  mixes  are 
presented  in  this  chapter.  In  addition,  we  present  considerations  that  should 
help  the  user  analyze  the  results  of  a  simulation  run. 

A.  WORKING  WITH  FELIX 

In  this  section,  we  illustrate  the  steps  required  to  set  up  and  run  a 
performance  evaluation  of  fleet  mix  alternatives.  Specifically,  we  address  how 

the  user  will: 

•  define  a  new  fleet  mix. 

•  select  parameters  as  initial  conditions  for  the  simulation  process. 

•  perform  the  simulation. 

•  analyze  the  results. 

1.  Initial  View 

Initially,  the  user  will  view  the  main  menu  of  Felix.  This  is  illustrated 
in  Figure  5-1.  Several  operations  are  possible  from  this  screen.  We  will  only 
discuss  the  process  of  stepping  a  user  through  a  typical  simulation  process. 
Other  options  available  to  the  user  are  explained  in  the  Felix  user's  manual. 

The  first  action  required  by  the  user  will  be  to  start  the  Oracle  database 
by  selecting  the  Start  Oracle  button.  Internally,  the  procedures  described  in 
the  previous  section  will  occur  and  the  link  between  the  user  interface  and 
the  database  will  be  established.  The  user  may  define  a  new  fleet  mix 
alternative,  modify  a  fleet  mix  alternative  or  continue  with  the  simulation 
setup  of  all  fleet  mix  alternatives  already  defined.  To  build  a  new  fleet  mix 
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alternative,  the  user  selects  the  Build  Fleet  button.  Felix  will  display  the 

screen  illustrated  in  Figure  5-2. 

■ 


U.S.  Department 
of  Transportation 

United  States 
Coast  Guard 


Felix  Hill 

LEETMIX: 
cision  Support 
System 


Start  Oracle 


Stop  Oracle 


Help 


Cancel 


Add  to  Que 


Done 


Figure  5-1  Main  Menu  in  Felix. 

2.  Build  a  Fleet 

Two  screens  are  used  to  build  a  new  fleet.  In  the  first  screen,  the  user 
assigns  a  fleet  mix  number  and  selects  the  number  of  patrol  boats  for  each 
class.  When  completed,  the  user  selects  the  Done  button;  the  second  screen  in 
the  Build  Fleet  process  appears.  The  user  assigns  each  vessel  to  one  of  the 
listed  patrol  boat  homeports.  The  homeports  are  automatically  linked  to  the 
proper  Coast  Guard  district  within  the  DSS.  The  result  is  a  fleet  mix 
alternative  that  defines  the  vessel  class,  homeport  and  district  for  each  boat. 
Up  to  five  fleet  mix  alternatives  can  be  defined  and  stored  in  the  DSS  in  this 
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manner.  Upon  completion,  the  user  selects  the  done  button  and  is  returned 
to  the  main  menu. 


U.S.  Department 
of  Transportation 

United  States 
Coast  Guard 


Felix 

FLEET  MIX: 
Decision  Support 
System 


K^^^FIeet  Mix  Construction 


Figure  5-2  Build  Fleet  Mix  Screen. 

3.  Simtdation  Process 

To  set  up  the  simulation,  user  selects  the  Run  Simulation  button  on 
the  main  menu.  Felix  will  display  the  Simulation  Input  screen  as  illustrated 

in  Figure  5-3.  Each  simulation  run  is  defined  as  follows: 

•  select  one  of  the  eight  fleet  mix  alternatives. 

•  select  a  district  for  evaluation. 

•  select  the  initial  sea  state  (weather  condition). 

•  select  the  trend  in  the  sea  state  (how  the  sea  state  changes  during  the 
run). 
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•  select  the  tempo  of  operation  (a  parameter  which  will  eventually  control 
the  rate  of  random  event  occurrence). 

The  parameters  for  the  first  simulation  run  are  now  defined  and  are 
stored  in  the  Simulation  Queue  data  table.  The  user  may  enter  additional 
simulation  runs,  varying  the  fleet  mix  number,  the  district  and  initial 
conditions  for  the  simulation.  One  requirement  is  to  evaluate  each  fleet  mix 
alternative  in  each  district  under  a  variety  of  conditions.  Another 
requirement  is  to  evaluate  each  fleet  mix  alternative  under  the  same  set  of 
simulation  parameters. 


!i%i%;%Simulation  Inputs  Required 
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of  Transportation 
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Coast  Guard 


Felix 

FLi:;!:;!  MIX; 
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Figure  5-3  Simulation  Inputs  Screen. 

With  the  simulation  queue  loaded,  the  user  selects  the  Execute  button 
to  initiate  the  simulation.  Felix  displays  the  Model  Base  Control  screen.  First 
Nexpert  is  initialized.  The  process  described  in  the  interface  section 
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establishes  a  link  between  the  user  interface  and  Nexpert.  Next  the  user 
selects  the  Perform  Simulation  button.  Program  control  passes  to  Nexpert. 
The  first  entry  in  the  simulation  queue  table  is  read.  The  patrol  boats  for  the 
selected  fleet  mix  and  district  are  positioned  on  an  imaginary  coastal  ocean 
area.  Some  vessels  are  at  sea  on  patrol.  Other  vessels  are  inport  either  in  a 
standby  condition  or  in  a  maintenance  condition.  A  random  event  occurs  at 
some  location.  The  simulation  dispatcher  selects  the  boat  that  should 
respond  to  the  event.  The  intercept  course  is  computed  for  the  selected  patrol 
boat  and  its  speed  is  set  to  maximum  speed.  The  model  computes  values  for 
measures  such  as  the  time  required  to  intercept  a  vessel,  and  the  fuel  used. 

The  process  is  continued  for  a  simulated  time  of  one  week,  with 
random  events  occurring  throughout  the  168  hour  time  frame.  Results  for 
the  simulation  run  are  stored  in  a  data  table  for  later  processing  or  review. 
The  next  run  in  the  simulation  queue  is  read  in  and  the  process  repeats.  The 
simulation  continues  until  all  Simulation  Queue  table  inputs  have  been 
evaluated. 

The  user  may  aggregate  the  simulation  results  or  return  to  the  main 
menu.  By  selecting  the  Aggregate  Results  button,  t’'"  Felix  aggregation  model 

w 

first  combines  simulation  results  by  district  w.  ..in  a  specific  fleet  mix 
alternative.  For  example,  five  simulation  runs  were  performed  on  FM02  in 
District  7.  The  first  level  of  aggregation  combines  the  results  for  District  7  of 
FM02.  The  first  level  aggregation  is  continued  until  results  are  combined  for 
each  district  of  each  fleet  mix  alternative.  The  second  level  of  aggregation 
combines  the  district  results  for  each  fleet  mix  alternative.  The  result  is  a 
display  of  measures  for  each  fleet  mix  alternative  in  the  final  results  screen. 
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The  summary  information  of  one  fleet  mix  is  presented  with  similar 
information  for  the  other  fleet  mix  alternatives.  Assessment  of  the  final 
results  is  discussed  later. 

4.  Typical  Results 

At  the  Main  Menu,  the  user  selects  the  Final  Results  button  and  a 
layout  similar  to  TABLE  5-1  is  displayed  on  the  screen.  The  numbers  are 
provided  for  demonstration  purposes,  and  have  no  relationship  to  a  real 
fleet.  Additionally,  the  cost  and  activity  measures  are  not  computed  in  the 
current  implementation.  The  user  has  the  option  of  printing  the  results  table 
or  returning  to  the  main  menu. 

The  user  can  get  more  information  about  a  number  on  the  simulation 
results  by  selecting  that  number.  Another  view  of  the  data  used  to  develop 
the  number  is  presented.  For  example,  the  user  might  want  to  look  at  the 
individual  simulation  results  that  were  performed  during  evaluation.  The 
user  clicks  on  the  fleet  mix  number  with  the  mouse  button.  A  scrolling  list 
appears  on  the  screen  with  all  the  simulation  runs  listed.  Clicking  on  one  of 
the  simulation  listings  causes  the  individual  results  to  be  displayed.  Figure  5- 
4  shows  sample  results  for  a  simulation  run.  This  completes  the  introductory 
steps  in  working  with  Felix.  Detailed  information  can  be  found  in  the  Felix 
User's  Manual  and  with  the  Online  Help  system  within  Felix. 
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TABLE  5-1  SAMPLE  FLEET  ANALYSIS  RESULTS. 


Evaluation  Measure 

FM04 

FM05 

FM06 

Costs  ($  millions) 

Amortized  Lifecycle  Cost 

$600 

$530 

$450 

Patrol 

1  72,800 

142,800 

136,800 

Maintenance 

Defense  Operations 

Performance 

SAR  response  time 

3.6  hours 

4.9  hours 

Number  of  SAR  missions 

27 

26 

27 

Number  of  failed  SAR 
missions 

2 

4 

5 

Number  of  ELT  missions 

1  7 

1  7 

1  7 

Number  of  failed  missions 

4 

6 

7 

Number  of  ELT  intercepts 

8 

6 

6 
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Felix  Single  Simulation  Results  Table 


Fleet  Mix; 
District: 


Patrol 

Maintenance 
Defense  Operations 


SAP  response  time 
Number  of  SAR  missions 
Number  of  failed  SAR 
missions 

Number  of  ELT  missions 
Number  of  failed  missions 
Number  of  ELT  intercepts 


Sea  State: 
Tempo: 


Amortized  Lifecycle  Cost  I  $155 


3.4  hrs  (AVG) 
17 
2 


Print 


5  /  Increasing 
Normal 


Fleet  Mix  Status 


District  Status 

WPB80  6 

WPB110  10 

WPB120  3 


Homeport  Status 

Mobile.  AL  WPB110 
Galveston,  TX  WPB80 
Galveston,  TX  WPB80 
Sabine.  TX  WPB120 
Freeport,  TX  WPB110 
Giilfnnrt  MS  WPRtin 


Figure  5-4  Results  for  a  Single  Simulation. 


B.  FLEET  MIX  ANALYSIS  USING  FELIX 

The  process  of  evaluating  fleet  mixes  has  been  discussed  above.  The  most 
important  use  of  the  fleet  mix  DSS  is  to  compare  alternative  fleet  mixes.  This 
section  provides  a  discussion  of  the  comparison  process.  Decision  makers 
will  develop  and  use  their  own  policies  for  combining  the  results.  The  next 
section  presents  some  considerations  for  use  of  results.  The  following 
questions  are  addressed:  What  do  the  results  imply  about  the  relative  quality 
of  the  fleet  mix?  How  can  the  decision  maker  use  the  results  of  the  DSS  to 
support  his  selection  of  a  fleet  mix  alternative? 
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1.  Perfonnance  Analysis 

The  performance  results  are  used  to  indicate  the  relative  quality  of  the 
fleet  mix  with  respect  to  meeting  mission  goals.  The  same  basis  for 
evaluation  must  be  used  to  ensure  objective  comparison.  Each  fleet  mix 
should  have  been  put  through  the  same  test  or  series  of  simulation  runs. 
TABLE  5-1  provided  sample  results  of  fleet  mix  analysis.  The  sample  results 
indicate  that  fleet  mix  FM04  has  a  better  performance  in  most  categories 
compared  to  the  other  fleet  mixes.  More  detail  about  the  performance  results 
is  obtained  by  clicking  with  the  mouse  on  the  fleet  mix  name  at  the  top  of  the 
column. 

2.  Cost  Analysis 

TABLE  5-1  indicates  that  fleet  mix  FM06  has  the  lowest  cost  figures 
compared  to  the  other  fleet  mixes.  The  cost  figures  would  be  entered  by  the 
user  for  each  class  of  ship,  and  this  table  would  show  the  cost  for  the  specified 
mix  in  the  fleet.  More  detail  about  the  costs  is  obtained  by  clicking  on  the 
number  in  question. 

3.  Activity  Analysis 

TABLE  5-1  indicates  that  fleet  mix  FM04  has  the  best  activity  capability 
for  patrol  boat  performance  and  the  lowest  maintenance  requirement.  The 
activity  characteristics  for  each  patrol  boat  are  entered  by  the  user.  Felix 
computes  the  combined  activity  hours  for  the  fleet  mix. 

This  chapter  discussed  use  of  the  DSS  to  help  the  user  evaluate  and 
compare  alternative  fleet  mixes.  Chapter  VI  discusses  considerations  for  use 
of  the  DSS,  and  presents  recommendations  for  enhancement  and 
improvement. 
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VI.  CONCLUSIONS 


Felix  was  designed  as  a  prototype  DSS  for  Coast  Guard  fleet  mix  planning. 
The  system  has  been  delivered  to  the  Patrol  Boat  Capability  Replacement 
Project  at  Coast  Guard  headquarters.  We  hope  that  further  enhancements 
and  modifications  will  be  added  to  improve  the  utility  of  the  DSS.  In  this 
chapter  we  present  the  known  limitations  of  the  system,  a  list  of  possible 
enhancements  to  the  system,  and  issues  for  further  research. 

A.  LIMITATIONS  OF  THE  CURRENT  IMPLEMENTATION 

There  are  certain  limitations  on  the  use  of  the  current  implementation  of 
Felix.  The  DSS  is  applicable  in  a  narrow  range  of  fleet  mix  planning.  The 
analysis  methods  used  do  not  consider  all  the  facets  of  patrol  boat 
performance.  Assumptions  were  made  for  the  evaluation  of  fleet  mix 
performance  that  provide  a  situation  different  from  the  real  world. 

1.  Applicability 

Felix  addresses  only  a  portion  of  the  patrol  boat  acquisition  planning 
phase  that  is  one  phase  of  the  larger  fleet  mix  planning  problem.  The  DSS 
helps  during  some  early  phases  of  the  A-109  process,  but  there  are  five  phases 
and  milestones  required  for  a  major  system  acquisition.  Many  other  aspects 
of  the  patrol  boat  fleet  mix  problem  not  addressed  including  the  size  of  the 
fleet,  the  location  of  the  vessels  and  the  use  of  other  vessels  to  perform  SAR 
and  ELT  missions.  Considerations  for  improving  the  DSS  are  discussed  later 
in  the  chapter. 
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2.  Analysis  Methods 

The  evaluation  process  for  performance  is  limited  in  the  following 


ways: 

•  The  simulation  is  performed  using  tables  for  events  and  tables  for  initial 
assignment  of  vessels.  The  event  tables  can  be  modified  to  reflect  any 
environment  desired.  Initial  condition  tables  can  be  modified  to  meet 
the  realistic  positioning  of  ships.  It  is  important  that  the  data  entered  in 
the  event  and  initicil  condition  tables  be  representative  of  the  fleet  mix 
problem  being  studied. 

•  The  simulation  occurs  in  a  rectangular  area  with  dimensions  closely 
approximating  each  district.  The  modeling  of  the  actual  geography  of  the 
coastal  United  States  was  not  feasible  for  this  prototyjje.  Similarly, 
islands  and  shoal  water  are  not  considered. 

•  The  simulation  does  not  consider  the  effects  of  fatigue  on  the  crew.  For 
example,  there  is  no  limit  on  the  number  of  ELT  boardings  that  a  patrol 
boat  could  perform  during  a  day,  other  than  the  assignment  to  one 
mission  precludes  an  overlapping  assignment  to  another  mission. 

•  Use  of  other  Coast  Guard  assets  is  not  considered.  The  missions  of  other 
assets  overlap.  In  reality,  40  foot  boats  and  helicopters,  along  with  other 
vessels  perform  SAR  missions.  Many  other  sensors,  ships  and  aircraft 
coordinate  their  efforts  at  the  illicit  drug  problem. 

3.  Underlying  Assumptions 

The  following  assumptions  were  made  during  the  development: 

•  Helicopters  and  other  Coast  Guard  assets  will  not  be  used  to  respond  to 
any  of  the  events  generated  in  Felix. 

•  Navigational  hazards  will  not  be  a  factor  in  oi  '  lalysis. 

•  Transit  time  through  restricted  waterways  do  not  impose  speed 
limitations  on  the  cutters. 

•  The  search  part  of  SAR  is  not  considered.  The  evaluation  model  directs 
the  patrol  boat  to  the  location  of  the  casualty. 

B.  ENHANCEMENTS  TO  THE  PROTOTYPE 

Felix  is  in  the  infant  stage  of  development.  There  are  several  paths  that 
can  be  taken  to  enhance  the  system  via  small  changes  to  Felix.  Larger 
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modifications  and  additions  to  the  system  are  covered  in  Section  C.  We  will 
discuss  how  the  system  can  be  enhanced  in  four  major  categories:  Program, 
Data,  Maintenance  and  Security. 

1.  Program  Eirhancements 

Program  enhancements  include  coding,  scripting,  icons,  color,  sound 
and  new  software  applications.  The  following  are  some  of  the  program 

enhancements  we  would  like  to  see  added  to  Felix. 

•  Provide  a  selection  of  randomly  generated  event  scenarios  for  the 
simulation.  Each  event  scenario  specifies  a  sequence  of  events  that  will 
occur  during  the  evaluation.  Different  scenarios  would  test  different 
aspects  of  patrol  boat  performance. 

•  Provide  a  selection  for  the  patrol  boat  initial  conditions  for  the 
simulation.  The  initial  conditions  include  the  location,  fuel  remaining, 
hours  underway  and  the  current  mission  of  the  patrol  boats  within  the 
district.  Evaluation  with  different  initial  conditions  will  reduce  the 
evaluation  bias  that  might  otherwise  be  caused  with  only  one  initial 
condition  for  the  steirt  of  the  simulation  process. 

•  Allow  the  user  to  define  a  simulation  set.  A  simulation  set  specifies  all 
the  simulation  runs  to  be  performed  on  a  fleet  mix.  The  simulation 
parameters  for  each  run  are  also  specified.  By  evaluating  each  fleet  mix 
using  the  same  simulation  set  or  sets,  the  user  is  assured  of  a  common 
base  for  comparing  performance  of  fleet  mix  alternatives. 

•  Provide  color  enhancements  to  the  user  interface  if  justified.  The 
capability  exists  with  the  present  design,  but  it  was  not  implemented. 

•  Provide  sound  enhancements  to  the  user  interface.  This  feature  could 
help  the  user  identify  the  type  of  error  committed  and  provide  extra 
clues  about  the  location  within  the  program. 

2.  Data  Enhancements 

Data  enhancements  provide  additional  information  that  could  be  used 
by  Felix  to  facilitate  better  analysis  for  the  decision  maker.  Several  of  the  tasks 
accomplished  in  Felix  use  data  that  is  entered  by  the  user.  The  best  method 
would  be  to  gather  and  analyze  appropriate  historical  data.  The  DSS  could 
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use  actual  historical  data  to  develop  event  tables  or  produce  probability 
distributions  that  could  be  used  in  a  Monte  Carlo  type  of  simulation. 

Examples  where  this  method  may  be  useful  are: 

•  the  distribution  of  SAR  cases  in  the  water  around  the  major  harbors, 
waterways  and  channels. 

•  the  analysis  of  historical  costs  to  be  used  in  lifecycle  cost  computation, 
(maintenance,  overhaul,  mid-life  maintenance,  operations,  etc.) 

•  the  location  of  fish  havens  that  are  most  likely  used  by  fishing  fleets. 

3.  Maintenance  Enhancements 

Presently,  the  maintenance  module  of  the  DSS  has  not  been 
implemented.  The  design  of  the  interface  delivered  with  Oracle  and  Nexpert 
do  not  provide  for  maintenance  through  the  SuperCard  interface. 
Maintenance  of  the  user  interface  is  performed  using  SuperEdit,  a  program 
delivered  with  SuperCard.  It  comes  with  all  the  tools  for  designing  new 
SuperCard  applications  and  modifying  existing  applications.  Additions  and 
modifications  to  the  database  structure  and  design  are  performed  using  the 
Oracle  System  Stack.  This  is  a  HyperCard  stack  that  provides  the  database 
administrator  the  features  to  manage  access,  tables  and  data.  Any  access  to  the 
Oracle  database  requires  a  valid  user  name  and  password.  The  model  base  is 
modified  using  Nexpert's  development  environment.  New  models  can  be 
developed  entirely  within  Nexpert  or  can  be  called  using  some  of  Nexpert's 
built  in  features  for  accessing  external  programs. 

Enhancements  to  the  Maintenance  module  would  include  a  call  from 
the  user  interface  to  Nexpert  that  would  completely  shut  down  the  user 
interface  after  connection.  Nexpert  could  then  be  used  in  the  development 
mode  to  do  maintenance  requirements.  Upon  completion,  Nexpert  would 


58 


restart  Felix,  establish  a  link  and  pass  program  control.  A  similar  process 
would  be  required  for  Oracle. 

4.  Security  Enhancements 

The  DSS  security  involves  two  phases.  The  first  is  controlling  access  to 
the  computer  through  physical  security.  The  second  phase  involves 
computer  hardware  or  software  that  restricts  computer  use  to  authorized 

persons.  The  security  measures  implemented  by  software  in  Felix  are: 

•  Access  to  the  Felix  DSS  user  interface  is  password  controlled.  Other 
SuperCard  applications  are  not  protected. 

•  Access  to  Oracle  requires  user  name  and  password. 

•  Access  to  Nexpert  Object  is  not  restricted  but,  access  to  Nexpert  is 
controlled  by  use  of  a  hardware  key  that  must  by  installed  for  proper  use. 

C.  ISSUES  FOR  FURTHER  RESEARCH 

The  DSS  discussed  in  this  thesis  was  designed  to  allow  the  developer  or 
user  to  make  improvements  and  modifications  within  the  existing 
framework.  Several  enhancements  have  already  been  discussed.  Other 
major  areas  for  research  include  development  of  other  models  and  expanding 
the  scope  of  problems  addressed  by  the  system. 

1.  Cost  Models 

Cost  analysis  is  not  provided  in  the  initial  version  of  the  prototype  fleet 
mix  DSS.  Determination  of  cost  is  an  important  aspect  of  the  fleet  mix 
problem.  This  is  an  important  component  for  further  development.  The 
costs  models  could  be  developed  within  Nexpert  or  could  use  Nexpert's 
features  to  call  an  external  program  like  an  optimization  model  or  a 
spreadsheet. 
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2.  Activity  Models 

Activity  analysis  is  also  an  important  measure  in  fleet  mix  planning.  It 
could  help  the  decision  maker  determine  how  many  vessels  are  required  in  a 
district  to  meet  a  certain  level  of  demand.  The  activity  model  could  be 
written  entirely  in  Nexpert  or  could  rely  on  Nexpert  to  call  an  external 
program. 

3.  Performance  Models 

The  performance  models  used  in  this  research  do  not  evaluate  use  of 
other  Coast  Guard  assets.  Further  research  could  include  development  of 
models  for  use  by  the  Navy,  Army  or  other  branches  within  the  Coast  Guard. 

4.  Expand  to  Other  Aspects  of  the  A-109  Process 

The  system  could  be  augmented  with  features  that  address  the  other 
phases  and  milestones  of  the  A-109  process.  Possible  enhancements  to  the 
system  include  a  more  elaborate  cost  evaluation  meeting  the  requirements  of 
the  lifecycle  cost  analysis  of  the  A-109  Circular.  Further,  an  important 
enhancement  would  be  the  development  of  reports  with  justification  needed 
for  certain  milestones. 

D.  SUMMARY 

This  research  has  built  on  previous  fleet  mix  planning  research.  In 
particular,  the  efforts  of  the  Coast  Guard  Patrol  Boat  Capability  Replacement 
Branch  [Ref.  8],  the  Coast  Guard  Research  and  Development  Center  [Ref.  13], 
and  the  Balance  Sheet  Approach  to  Fleet  Mix  Planning  [Ref.  3]  were  used  to 
design  and  develop  a  working  prototype  tool  for  fleet  mix  planning  in  the 
Coast  Guard.  Though  the  implementation  of  our  design  is  partial,  early 
feedback  from  the  Coast  Guard  has  been  encouraging.  The  system 


60 


enhancements  and  additional  research  topics  would  add  greatly  to  the 
capability  of  the  system.  The  goal  of  the  design  team  has  been  realized.  We 
hope  the  project  will  continue,  and  that  better  fleet  mix  decisions  will  be 
possible  as  a  result  of  using  this  tool. 


61 


LIST  OF  REFERENCES 


1.  Coast  Guard  Overview  1989  -  1990, 200  Years  of  Service,  1990. 

2.  U.S.  Coast  Guard,  Candidate  WPB  Craft  Study  (Second  Analysis),  Office  of 
Research  and  Development  (G-D),  U.S.  Coast  Guard  Headquarters,  Washington 
D.C.,  1987. 

3.  Bhargava,  Hemant,  Steven  O.  Kimbrough,  and  Clark  W.  Pritchett,  A  Balance  Sheet 
Approach  to  Fleet  Mix  Planning,  University  of  Pennsylvania,  Department  of  Decision 
Sciences  working  paper,  1990. 

4.  United  States  Coast  Guard  Memorandum  G-OP/32,  Mission  Needs  Statement  for 
WPB  Capability  Replacement  of  1  June  1983,  Jul  1983. 

5.  Emery,  James  C.,  Management  Information  Systems:  The  Critical  Strategic  Resource, 
Oxford  University  Press,  1987. 

6.  Department  of  Defense  Directive  5000.1,  Policies  Governing  Major  and  Nonmajor 
Defense  Acquisition  Programs,  July  1, 1990.  (Draft  Copy) 

7.  Pritchett,  Clark,  Predicting  Patrol  Performance,  paper  presented  at  56th  MORS,  29 
June  1988. 

8.  Pritchett,  Clark  W.  and  S.  F.  Roehrig,  Search  and  Rescue  Monte  Carlo  Simulation, 
Report  No.  CG-D- 12-86,  U.S.  Coast  Guard  Research  and  Development  Center, 
March  1985. 

9.  Himes,  Andrew  and  Craig  Ragland,  Inside  SuperCard,  Microsoft  Press,  Redmond, 
Washington,  1990. 

10.  Department  of  Defense  Directive  4245.7-M,  Transit!  ^  '^rom  Development  To 
Production. ..Solving  The  Risk  Equation,  Septembei  65. 

11.  Interview  between  Clark  Pritchett,  U.S.  Coast  Guard  R&D  Center,  Groton,  CT,  and 
the  authors,  4  December  1990. 

12.  Trutna,  Rick  and  Catherine  Mone,  ORACLE  for  Macintosh  Reference  .Version  1.2, 
Oracle  Coporation  1990. 

13.  Neuron  Data  Corportation,  N EXPERT  OBJECT:  Database  Inegration  Guide  Version 
2.0,  Neuron  Data  1991. 

14.  Neuron  Data  Corportation,  The  NEXPERT  HyperBridge:  Version  2.0  User's 
Manual,  Neuron  Data  1990. 


62 


15.  Schneiderman,  Ben,  Designing  the  User  Interface:  Stratgiesfor  Effective  Human- 
Computer  Interaction,  Addison-Wesley  Publishing  Company,  1987. 


63 


INITIAL  DISTRIBUTION  LIST 


No.  Copies 


1.  Defense  Technical  Information  Center  2 

Cameron  Station 

.Alexandria,  Virginia  22304-6145 

2.  Library,  Code  52  2 

Naval  Postgraduate  School 

Monterey,  California  93943-5100 

3.  Professor  Hemant  K.  Bhargava  (Code  AS/BH)  1 

Naval  Postgraduate  School 

Monterey,  California  93943-5002 

4.  Professor  Gordon  Bradley  (Code  OA/BZ)  1 

Naval  Postgraduate  School 

Monterey,  California  93943-5002 

5.  Professor  Michael  G.  Sovereign  (Code  OR/SM)  1 

Naval  Postgraduate  School 

Monterey,  California  93943-5002 

6.  Commandant  (G-AWP)  2 

U.  S.  Coast  Guard 

2100  Second  St.  S.W. 

Washington,  D.C.  20593 

7.  Clark  W.  Pritchett  1 

U.S.  Coast  Guard  Research  and  Development  Center 

Avery  Point,  Groton,  Connecticut  06340 

8.  Capt.  William  G.  Simpson  1 

Commandant  (G-AWP) 

U.  S.  Coast  Guard 
2100  Second  St.  S.W. 

Washington,  D.C.  20593 


64 


Steven  O.  Kimbrough 
The  Wharton  School 
3620  Locust  Walk  #  1300 
Philadelphia,  Pennsylvania  19104-6366 

Professor  Keebam  Kang,  Code  AS/KK 
Naval  Postgraduate  School 
Monterey,  California  93943-5002 

LCDR  Thomas  J.  Kaiser 
167  Centerview  Drive 
Portsmouth,  Rhode  Island  02871 

LT  Louis  A.  Cortez 

957  West  Goodview  Drive 

Virginia  Beach,  Virginia  23464 


